<div dir="ltr">A transparent proxy is just out of the question. As HamWAN's license trustee, I'm not at all comfortable setting up a man-in-the-middle attack so that secure websites are sent to users in the clear, with or without their consent. There would almost certainly be unforeseen ramifications to that. Keep in mind that when you view that traffic in the clear, you're not just seeing the content shown to the user. You're also seeing things like session tokens and passwords that would allow you to impersonate that user. There are just too many liability traps to fall in when going down that path.<div><br></div><div>For those who want help maintaining their compliance, there are two paths that I believe would be viable...</div><div><br></div><div>The first would be to use VNC or any other remote desktop protocol in the clear to connect to a remote host on the internet. You can then use the browser on that host without needing to worry about obscured traffic, since the resulting display would always be in the clear.</div><div><br></div><div>The other option would be to create a custom browser that can be toggled into a specific part 97 mode. That mode would enforce specific policies when communicating, as well as re-enable the option for null ciphers that have long been removed from modern browsers.</div><div><br></div><div>On the other hand, I'm not sure the effort to implement those solutions would be worthwhile. The prohibition on obscured content is one of those necessary things that helps us self-regulate our bands to make sure they're not taken over by the commercial interests that desperately want them. However, we're in a bit of a special case here because of the packet-switched nature of our network. Unlike in other data modes, the user who occasionally sends obscured traffic isn't preventing anyone else from using our RF resources unless they start consuming all of our available bandwidth. That's why our approach to this problem has always been very lax. We make every attempt to comply with the letter of part 97 and help others do the same, but failing that doesn't impact us like it would on other modes.</div><div><br></div><div>Also, web browsing is not the primary purpose of the HamWAN network. We're here to provide a reliable and well engineered backbone to connect ham-based services and users. Things like repeater linking, VoIP calling, remote video feeds, APRS-IS, winlink servers, and more do not require obscured traffic. If you also need to provide emergency internet access to someone's browser, have at it. However, web traffic to internet sites should not be your primary use-case for being on HamWAN.</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Aug 16, 2019 at 11:00 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>For ease of discussion I'll refer to the idea of bypassing encryption on the web for P97 compliance as "NO-CRYPT."<br></div><div><br></div><div>First a couple of general comments:<br></div><div><br></div><div>1) My expectation is that NO-CRYPT would be most useful during times of non-emergency. During declared emergencies, and assuming a permissive stance by the FCC, NO-CRYPT or equivalent should be immediately disabled. This would address the issue of "civilians" like hospital employees not having unfettered access to content on the web via HamWAN.<br></div><div><br></div><div>2) Perfection would be nice, but it's not a design requirement. If NO-CRYPT increases the usefulness of HamWAN even to a modest degree during non-emergency operations by enabling access to additional web content, I would count that as a win. <br></div><div><br></div><div>3) There's nothing to prevent any particular HamWAN connected sites from simply not using the NO-CRYPT scheme if they choose to. The main intention is to find a way to make as much web content accessible as possible during non-emergency times, and thereby increase the usefulness of HamWAN for any participants wanting to do so. Maybe <a href="http://google.com" target="_blank">google.com</a> can't be accessed via HamWAN during non-emergency times. If so, I'll still sleep at night.<br></div><div><br></div><div>Echoing Bryan's comment, I too would be concerned that any clarification of Part 97 could be made to the detriment of us all. As lawyers are apt to say: Never ask a question unless you already know the answer. That applies well to the FCC.<br></div><div><br></div><div>As to Doug's comment, I would like as much as possible to avoid a user having to do much of any config or tweaking on their browser, such as specifying a web proxy. That may end up being unavoidable, but I'm starting with goal of not requiring that. That's why I'm focused (for the moment) on using a transparent proxy. <br></div><div><br></div><div id="gmail-m_-3748418491535869303Zm-_Id_-Sgn"><div><div><br></div><div>I'm aware of Expect-CT, certificate pinning, and HSTS. There are other obstacles that have not even been mentioned. But I guess we'll have to see what testing shows. <br></div><div><br></div><div>I repeat: Implementing NO-CRYPT for web traffic is very non-trivial, but it may be workable. <br></div><div><br></div><div>John C. Miller<br></div><div><a href="mailto:kx7jm@jmit.com" target="_blank">kx7jm@jmit.com</a><br></div><div>(530)873-9005<br></div></div><div><br></div></div><div class="gmail-m_-3748418491535869303zmail_extra"><div><br></div><div id="gmail-m_-3748418491535869303Zm-_Id_-Sgn1">---- On Fri, 16 Aug 2019 19:13:50 -0700 <b>Jake Visser <<a href="mailto:visser.jacob@outlook.com" target="_blank">visser.jacob@outlook.com</a>></b> wrote ----<br></div><div><br></div><blockquote style="border-left:1px solid rgb(204,204,204);padding-left:6px;margin:0px 0px 0px 5px"><div class="gmail-m_-3748418491535869303zm_-7921335677902783707_parse_-595698474028852375"><div class="gmail-m_-3748418491535869303x_1080696893WordSection1"><p class="MsoNormal">> From reading the draft, it looks like adding a root cert will still allow over<br> riding this</p><p class="MsoNormal"> <br></p><p class="MsoNormal">Your right – that is the intent; but in current implementations, it’s the “it is acceptable” wording that is interpreted. In all cases so far the “SHOULD NOT” submit a report is honored, but Chrome isn’t going to let you load google using
any certificate not issued by a google. There are ways around this for enterprise deployments; and it probably is a fair assessment that hams could deploy a second browser configured in that manner… but for a general user, its going to be a lot harder than
just installing a new root cert.<br></p><p class="MsoNormal"> <br></p><div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0in 0in"><p class="MsoNormal" style="border:none;padding:0in"><b>From: </b><a href="mailto:Bryan@bryanfields.net" target="_blank">Bryan Fields</a><br> <b>Sent: </b>Friday, August 16, 2019 6:58 PM<br> <b>To: </b><a href="mailto:psdr@hamwan.org" target="_blank">Puget Sound Data Ring</a><br> <b>Subject: </b>Re: [HamWAN PSDR] Idea for addressing HTTPS on HamWAN</p></div><p class="MsoNormal"> <br></p><p class="MsoNormal">On 8/16/19 9:40 PM, Jake Visser wrote:<br> > Much like HSTS; Expect-CT is starting to be deployed too (this replaces<br> > certificate pinning). <br> > <a href="https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.mozilla.org%2Fen-US%2Fdocs%2FWeb%2FHTTP%2FHeaders%2FExpect-CT&data=02%7C01%7C%7Cecd5e4bb42b44a1451f608d722b6550a%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637016038809698674&sdata=kzuM9RFUO816UaYPT%2FpYBwcR1khLM86O1QLIK6PeMj0%3D&reserved=0" target="_blank"> https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.mozilla.org%2Fen-US%2Fdocs%2FWeb%2FHTTP%2FHeaders%2FExpect-CT&data=02%7C01%7C%7Cecd5e4bb42b44a1451f608d722b6550a%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637016038809698674&sdata=kzuM9RFUO816UaYPT%2FpYBwcR1khLM86O1QLIK6PeMj0%3D&reserved=0</a><br> > <br> > This will prevent users from accessing sites that are signed by a<br> > certificate that does not appear in the public transparency logs…<br> <br> From reading the draft, it looks like adding a root cert will still allow over<br> riding this. Is that not what 2.4.1 speaks of in there? I'll admit I'm not<br> up on the newest SSL standards.<br> <br> > The best option – if this is truly to be used for emergency communications<br> > – is to try the proposed FCC path.<br> <br> I would say we not try that. The FCC rules can be interpreted a number of<br> different ways now, it's likely if we ask for clarification they may do so in<br> a way making this all a violation. Right now the FCC rules are moot on<br> encryption, the word doesn't appear in part 97 at all.<br> <br> -- <br> Bryan Fields<br> <br> 727-409-1194 - Voice<br> <a href="https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbryanfields.net&data=02%7C01%7C%7Cecd5e4bb42b44a1451f608d722b6550a%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637016038809708685&sdata=B5gtHYNuNHid52YmaWu205rclAQzDiRyC5sMXi%2FKix4%3D&reserved=0" target="_blank">https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbryanfields.net&data=02%7C01%7C%7Cecd5e4bb42b44a1451f608d722b6550a%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637016038809708685&sdata=B5gtHYNuNHid52YmaWu205rclAQzDiRyC5sMXi%2FKix4%3D&reserved=0</a><br> _______________________________________________<br> PSDR mailing list<br> <a href="mailto:PSDR@hamwan.org" target="_blank">PSDR@hamwan.org</a><br> <a href="https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hamwan.net%2Fmailman%2Flistinfo%2Fpsdr&data=02%7C01%7C%7Cecd5e4bb42b44a1451f608d722b6550a%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637016038809708685&sdata=XPLFa%2FJlJkZanR4uB4CGLo9GAwhvREibuhu3NMnxLZs%3D&reserved=0" target="_blank">https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hamwan.net%2Fmailman%2Flistinfo%2Fpsdr&data=02%7C01%7C%7Cecd5e4bb42b44a1451f608d722b6550a%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637016038809708685&sdata=XPLFa%2FJlJkZanR4uB4CGLo9GAwhvREibuhu3NMnxLZs%3D&reserved=0</a></p><p class="MsoNormal"> <br></p></div></div><div>_______________________________________________<br></div><div>PSDR mailing list<br></div><div><a href="mailto:PSDR@hamwan.org" target="_blank">PSDR@hamwan.org</a><br></div><div><a href="http://mail.hamwan.net/mailman/listinfo/psdr" target="_blank">http://mail.hamwan.net/mailman/listinfo/psdr</a><br></div></blockquote></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>