[HamWAN PSDR] Idea for addressing HTTPS on HamWAN

[Doug Kingston]

What if the user is willing to cooperate by specifying a proxy to their
browser - does that help in any way here?

-Doug-

On Fri, Aug 16, 2019 at 12:56 PM John C. Miller <kx7jm at jmit.com> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.hamwan.net/pipermail/psdr/attachments/20190816/12819447/attachment.html>