[HamWAN PSDR] Idea for addressing HTTPS on HamWAN

[Nick Kartsioukas]

HSTS will probably be an issue but I don't think it's widely implemented (yet).

On Fri, Aug 16, 2019, at 12:56, John C. Miller wrote:
> All, 
> 
> Apologies for the lengthy post.
> 
> I've been mulling over potential solutions for the HTTPS over HamWAN 
> dilemmna: 
> Practically universal use of HTTPS web sites + Part 97 makes accessing 
> nearly all web content over HamWAN illegal, and severely limits the 
> utility of HamWAN.
> 
> I'm aware of discussions about HamWAN ceasing to be completely P97. But 
> for as long as HamWAN is even partially subject to P97, I think it's 
> worth looking for solutions or at least work-arounds to P97 
> limitations. Thus the subject of this post. (I also very much hope that 
> sectors are not abandoned in favor of PtP links only!)
> 
> From wearing a network security (white) hat I've used certain tools and 
> techniques for network penetration testing that may be helpful to us in 
> this case. I've just begun testing a methodology for a specialized type 
> of transparent proxy server that should enable some or much of the 
> encrypted content on the web (i.e. https:// sites) to be legally 
> accessed over HamWAN with http. The goal is for this to be essentially 
> transparent to the user, or nearly so.
> 
> The short version is that we would deploy a specialized type of 
> transparent web proxy server that splits off the SSL layer from web 
> requests and allows the transaction to flow non-encrypted over HamWAN 
> using http protocol (non-encrypted) which would be Part 97 compliant. 
> This same server would also circumvent a number of tactics in wide use 
> today that attempt to force web sessions to always use encryption 
> (https). Implementing such an approach is non-trivial, but I think 
> there is a reasonable chance that it can be done. There will almost 
> surely be some web sites that won't work well with this strategy, but 
> those will hopefully be relatively few.
> 
> A key piece of this strategy uses a network penetration testing tool 
> created in 2009, aptly called SSL-Split. This program was initially a 
> fairly simple but powerful tool that intercepted secure web sessions 
> (https:) by executing what's known as a man-in-the-middle attack. Using 
> an attack vector, a server running SSL-Split would insert itself 
> between the person's web browser, and the web server they were 
> accessing. The attacking SSL-Split server would then strip off the SSL 
> layer, making the payload of "secret" data no longer secret. At this 
> point the web session would continue un-encrypteed, and user data could 
> simply be captured, or manipulated. SSL-Split could then re-assemble 
> the SSL layer back onto the data stream on its way to the server. 
> Neither the web user, nor the web site being visited need be aware of 
> the chicanery going on.
> 
> 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.
> 
> I've glossed over some of the arcane details of this approach, but this 
> is the basic gist of it. I'm testing on a private network at home, and 
> packet sniffing the network to confirm that the data stream is indeed 
> un-encrypted where it needs to be.
> 
> I'll keep the list apprised of progress.
> 
> John Miller, KX7JM
> kx7jm at jmit.com
> (530)873-9005
> 
> 
> 
> _______________________________________________
> PSDR mailing list
> PSDR at hamwan.org
> http://mail.hamwan.net/mailman/listinfo/psdr
>