<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body>
<div>
<div>
<div>
<div style="direction: ltr;">I’m curious to see what the results are here - I do pentesting work full-time and see HSTS on basically every site that has auth requirements (e.g. is not just a static site) and is at least fairly well managed on the security side.</div>
<div><br>
</div>
<div style="direction: ltr;">That said, HSTS adoption is only around 10% right now (https://w3techs.com/technologies/details/ce-hsts/all/all) so this could go either way (though I suspect that the percentage is heavily biased by a lot of static sites that don’t
specify HSTS because they have no login forms/sensitive content/etc. and don’t bother). This fix would definitely render all of the major services (all Google services, Facebook, Twitter, Microsoft, Wikipedia, etc.) unusable, which seems like it may hinder
usage in an emergency when we find out that some critical system has HSTS and we can’t get to it.</div>
<div><br>
</div>
<div><br>
</div>
<div style="direction: ltr;">Dakota</div>
</div>
<div><br>
</div>
<div class="ms-outlook-ios-signature"></div>
</div>
<div> </div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="dir="ltr""><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> PSDR <psdr-bounces@hamwan.org> on behalf of Doug Kingston <dpk@randomnotes.org><br>
<b>Sent:</b> Friday, August 16, 2019 4:57 PM<br>
<b>To:</b> Puget Sound Data Ring<br>
<b>Subject:</b> Re: [HamWAN PSDR] Idea for addressing HTTPS on HamWAN
<div> </div>
</font></div>
<meta content="text/html; charset=utf-8">
<div dir="ltr">
<div class="gmail_default" style="font-size:small">What if the user is willing to cooperate by specifying a proxy to their browser - does that help in any way here?</div>
<div class="gmail_default" style="font-size:small"><br>
</div>
<div class="gmail_default" style="font-size:small">-Doug-</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Fri, Aug 16, 2019 at 12:56 PM John C. Miller <<a href="mailto:kx7jm@jmit.com">kx7jm@jmit.com</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left:1px solid rgb(204,204,204); padding-left:1ex">
<u></u>
<div>
<div style="font-family:Verdana,Arial,Helvetica,sans-serif; font-size:10pt">
<div>All, <br>
</div>
<div><br>
</div>
<div>Apologies for the lengthy post.<br>
</div>
<div><br>
</div>
<div>I've been mulling over potential solutions for the HTTPS over HamWAN dilemmna: <br>
</div>
<div>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.<br>
</div>
<div><br>
</div>
<div>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!)<br>
</div>
<div><br>
</div>
<div>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.<br>
</div>
<div><br>
</div>
<div>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.<br>
</div>
<div><br>
</div>
<div>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.<br>
</div>
<div><br>
</div>
<div>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. <br>
</div>
<div><br>
</div>
<div>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.<br>
</div>
<div><br>
</div>
<div>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.<br>
</div>
<div><br>
</div>
<div>I'll keep the list apprised of progress.<br>
</div>
<div><br>
</div>
<div>John Miller, KX7JM<br>
</div>
<div><a href="mailto:kx7jm@jmit.com" target="_blank">kx7jm@jmit.com</a><br>
</div>
<div>(530)873-9005</div>
<div><br>
</div>
<div><br>
</div>
</div>
<br>
</div>
_______________________________________________<br>
PSDR mailing list<br>
<a href="mailto:PSDR@hamwan.org" target="_blank">PSDR@hamwan.org</a><br>
<a href="http://mail.hamwan.net/mailman/listinfo/psdr" rel="noreferrer" target="_blank">http://mail.hamwan.net/mailman/listinfo/psdr</a><br>
</blockquote>
</div>
</div>
</body>
</html>