On 8/16/19 3:56 PM, John C. Miller wrote:
I say that SSL-Split *was* initially fairly simple, because in the 10 years since its creation a variety varied steps have been taken by browser developers and web engineers to force encryption to be used for all web traffic. But the developers of SSL-Split have evolved the program considerably and have kept pace to a large extent with current technology. The latest version of SSL-Split is much more powerful than early versions, with the capability of (among other things) essentially creating x.509 security certificates on the fly when needed, refusing certificate revocation status requests, bypassing HSTS, and other tactics that can neutralize the "forced https/encrypted" policies in wide use> The power of SSL-Split to convert web data streams from http to https and back is a central piece of the strategy that I'm examining. In the use case for HamWAN, we are using tools like SSL-Split not as an attack weapon, but rather as a data conversion utility. We insert our "conversion server" running SSL-Split and other tools into the appropriate place on the network, and let it do data stream conversion for us.
So question, why not just have it re-encrypt with a well known hamwan cert on the proxy. You can have the clients install this and trust it. It does take some work, but it gets around the major issues. Technically the data is still encrypted but if you publish the private keys, anyone can decrypt it. Part 97 is mostly concerned with the intent of hiding your communications. If you use encryption with a published key, it's for authentication and "kosher". Perhaps logging some flow data on SSL would be a good compromise on this too. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net