Idea for addressing HTTPS on HamWAN
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 mailto:kx7jm@jmit.com (530)873-9005
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@jmit.com (530)873-9005
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.net/mailman/listinfo/psdr
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@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@jmit.com (530)873-9005
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.net/mailman/listinfo/psdr
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. 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. Dakota ________________________________ From: PSDR <psdr-bounces@hamwan.org> on behalf of Doug Kingston <dpk@randomnotes.org> Sent: Friday, August 16, 2019 4:57 PM To: Puget Sound Data Ring Subject: Re: [HamWAN PSDR] Idea for addressing HTTPS on HamWAN 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@jmit.com<mailto:kx7jm@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@jmit.com<mailto:kx7jm@jmit.com> (530)873-9005 _______________________________________________ PSDR mailing list PSDR@hamwan.org<mailto:PSDR@hamwan.org> http://mail.hamwan.net/mailman/listinfo/psdr
I can't speak to the merits of John KX7JM's proposal (but it sounds ripe for investigation to me). I've just joined this list, so I haven't seen the previous discussion making HamWAN not Part 97. I'd like to throw out, for purposes of discussion, an alternative approach - request a Special Temporary Authority for "investigating" the use of https in networks that are to be compliant with Internet standards and interoperable with the Internet using the Amateur VHF, UHF, and microwave bands. If it's approved (and if memory serves, they almost always are, if they're sufficiently bounded; IE not much damage likely to be caused if the experiment doesn't work) then someone manages the STA, and as long as your name is listed as one of the investigators (and it's a formality to add someone), then you're covered. They get renewed every six months, and sometimes they can run for years. Eventually you accumulate enough "evidence" supporting, or disproving, what you're experimenting with, and submit a report, and usually a recommendation for a rules change. The rules change requested could be something like: On Amateur Radio bands > 50 MHz, when using a network that's intended to be compliant with and interoperable with current Internet standards, use of Secure Hypertext Protocol (https) is permitted, provided that the user's intent in using HTTPS is not to obscure communications. Such usage is typified by a website does not offer the option of the use of the unencrypted http protocol, only the https protocol. That gives the FCC leverage to go after someone they suspect of abuse by accusing them of intending to obscure communications. If HamWAN is to be truly useful to served entities in an emergency (like hospitals, etc.) they're not going to understand why it wouldn't / shouldn't work when accessing a website using https (explain this in excruciating detail). This proposal would be backed up by listing a number of sites highly useful to Amateur Radio that you might want to offer only https access. This proposed STA might be a great project for HamWAN to apply for a grant from ARDC to employ some paid legal to form and submit the STA request to insure that this is done properly so it has a reasonable change of succeeding. Thanks, Steve N8GNJ On Fri, Aug 16, 2019 at 12:56 PM John C. Miller <kx7jm@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@jmit.com (530)873-9005
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.net/mailman/listinfo/psdr
-- Steve Stroh (personal / general): stevestroh@gmail.com
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
Much like HSTS; Expect-CT is starting to be deployed too (this replaces certificate pinning). https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Expect-CT This will prevent users from accessing sites that are signed by a certificate that does not appear in the public transparency logs… The best option – if this is truly to be used for emergency communications – is to try the proposed FCC path. From: Bryan Fields<mailto:Bryan@bryanfields.net> Sent: Friday, August 16, 2019 6:28 PM To: psdr@hamwan.org<mailto:psdr@hamwan.org> Subject: Re: [HamWAN PSDR] Idea for addressing HTTPS on HamWAN 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 https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbryanfields.net&data=02%7C01%7C%7C005798704b674c2808b308d722b22b46%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637016020942378053&sdata=r90o1dke2vqpIvFroz8%2BnmYZvg2aV17w5n0%2B%2FAANWag%3D&reserved=0 _______________________________________________ PSDR mailing list PSDR@hamwan.org https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hamwan.net%2Fmailman%2Flistinfo%2Fpsdr&data=02%7C01%7C%7C005798704b674c2808b308d722b22b46%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637016020942388058&sdata=kyyBi3y08Jz43mjZIEoieZXFzWdsrmVWaeLmQ2DwshM%3D&reserved=0
On 8/16/19 9:40 PM, Jake Visser wrote:
Much like HSTS; Expect-CT is starting to be deployed too (this replaces certificate pinning). https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Expect-CT
This will prevent users from accessing sites that are signed by a certificate that does not appear in the public transparency logs…
From reading the draft, it looks like adding a root cert will still allow over riding this. Is that not what 2.4.1 speaks of in there? I'll admit I'm not up on the newest SSL standards.
The best option – if this is truly to be used for emergency communications – is to try the proposed FCC path.
I would say we not try that. The FCC rules can be interpreted a number of different ways now, it's likely if we ask for clarification they may do so in a way making this all a violation. Right now the FCC rules are moot on encryption, the word doesn't appear in part 97 at all. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
From reading the draft, it looks like adding a root cert will still allow over riding this
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. From: Bryan Fields<mailto:Bryan@bryanfields.net> Sent: Friday, August 16, 2019 6:58 PM To: Puget Sound Data Ring<mailto:psdr@hamwan.org> Subject: Re: [HamWAN PSDR] Idea for addressing HTTPS on HamWAN On 8/16/19 9:40 PM, Jake Visser wrote:
Much like HSTS; Expect-CT is starting to be deployed too (this replaces certificate pinning). 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
This will prevent users from accessing sites that are signed by a certificate that does not appear in the public transparency logs…
From reading the draft, it looks like adding a root cert will still allow over riding this. Is that not what 2.4.1 speaks of in there? I'll admit I'm not up on the newest SSL standards.
The best option – if this is truly to be used for emergency communications – is to try the proposed FCC path.
I would say we not try that. The FCC rules can be interpreted a number of different ways now, it's likely if we ask for clarification they may do so in a way making this all a violation. Right now the FCC rules are moot on encryption, the word doesn't appear in part 97 at all. -- Bryan Fields 727-409-1194 - Voice 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 _______________________________________________ PSDR mailing list PSDR@hamwan.org 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
For ease of discussion I'll refer to the idea of bypassing encryption on the web for P97 compliance as "NO-CRYPT." First a couple of general comments: 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. 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. 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 google.com can't be accessed via HamWAN during non-emergency times. If so, I'll still sleep at night. 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. 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. 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. I repeat: Implementing NO-CRYPT for web traffic is very non-trivial, but it may be workable. John C. Miller mailto:kx7jm@jmit.com (530)873-9005 ---- On Fri, 16 Aug 2019 19:13:50 -0700 Jake Visser <visser.jacob@outlook.com> wrote ----
From reading the draft, it looks like adding a root cert will still allow over riding this
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. From: mailto:Bryan@bryanfields.net Sent: Friday, August 16, 2019 6:58 PM To: mailto:psdr@hamwan.org Subject: Re: [HamWAN PSDR] Idea for addressing HTTPS on HamWAN On 8/16/19 9:40 PM, Jake Visser wrote:
Much like HSTS; Expect-CT is starting to be deployed too (this replaces certificate pinning). 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
This will prevent users from accessing sites that are signed by a certificate that does not appear in the public transparency logs…
From reading the draft, it looks like adding a root cert will still allow over riding this. Is that not what 2.4.1 speaks of in there? I'll admit I'm not up on the newest SSL standards.
The best option – if this is truly to be used for emergency communications – is to try the proposed FCC path.
I would say we not try that. The FCC rules can be interpreted a number of different ways now, it's likely if we ask for clarification they may do so in a way making this all a violation. Right now the FCC rules are moot on encryption, the word doesn't appear in part 97 at all. -- Bryan Fields 727-409-1194 - Voice 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 _______________________________________________ PSDR mailing list mailto:PSDR@hamwan.org 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 _______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.net/mailman/listinfo/psdr
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. For those who want help maintaining their compliance, there are two paths that I believe would be viable... 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. 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. 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. 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. On Fri, Aug 16, 2019 at 11:00 PM John C. Miller <kx7jm@jmit.com> wrote:
For ease of discussion I'll refer to the idea of bypassing encryption on the web for P97 compliance as "NO-CRYPT."
First a couple of general comments:
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.
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.
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 google.com can't be accessed via HamWAN during non-emergency times. If so, I'll still sleep at night.
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.
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.
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.
I repeat: Implementing NO-CRYPT for web traffic is very non-trivial, but it may be workable.
John C. Miller kx7jm@jmit.com (530)873-9005
---- On Fri, 16 Aug 2019 19:13:50 -0700 *Jake Visser <visser.jacob@outlook.com <visser.jacob@outlook.com>>* wrote ----
From reading the draft, it looks like adding a root cert will still allow over riding this
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.
*From: *Bryan Fields <Bryan@bryanfields.net> *Sent: *Friday, August 16, 2019 6:58 PM *To: *Puget Sound Data Ring <psdr@hamwan.org> *Subject: *Re: [HamWAN PSDR] Idea for addressing HTTPS on HamWAN
On 8/16/19 9:40 PM, Jake Visser wrote:
Much like HSTS; Expect-CT is starting to be deployed too (this replaces certificate pinning).
This will prevent users from accessing sites that are signed by a certificate that does not appear in the public transparency logs…
From reading the draft, it looks like adding a root cert will still allow over riding this. Is that not what 2.4.1 speaks of in there? I'll admit I'm not up on the newest SSL standards.
The best option – if this is truly to be used for emergency communications – is to try the proposed FCC path.
I would say we not try that. The FCC rules can be interpreted a number of different ways now, it's likely if we ask for clarification they may do so in a way making this all a violation. Right now the FCC rules are moot on encryption, the word doesn't appear in part 97 at all.
-- Bryan Fields
727-409-1194 - Voice
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 _______________________________________________ PSDR mailing list PSDR@hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.net/mailman/listinfo/psdr
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.net/mailman/listinfo/psdr
Thank you all for the thoughtful comments on the subject. Cory (NQ1E): Points all well taken. I will toss this idea on the junk pile along with the left-handed smoke shifter, which also seemed like a good idea... John C. Miller mailto:kx7jm@jmit.com ---- On Sat, 17 Aug 2019 00:28:44 -0700 Cory (NQ1E) <mailto:cory@nq1e.hm> wrote ---- 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. For those who want help maintaining their compliance, there are two paths that I believe would be viable... 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. 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. 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. 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. On Fri, Aug 16, 2019 at 11:00 PM John C. Miller <mailto:kx7jm@jmit.com> wrote: For ease of discussion I'll refer to the idea of bypassing encryption on the web for P97 compliance as "NO-CRYPT." First a couple of general comments: 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. 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. 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 http://google.com can't be accessed via HamWAN during non-emergency times. If so, I'll still sleep at night. 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. 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. 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. I repeat: Implementing NO-CRYPT for web traffic is very non-trivial, but it may be workable. John C. Miller mailto:kx7jm@jmit.com (530)873-9005 ---- On Fri, 16 Aug 2019 19:13:50 -0700 Jake Visser <mailto:visser.jacob@outlook.com> wrote ----
From reading the draft, it looks like adding a root cert will still allow over riding this
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. From: mailto:Bryan@bryanfields.net Sent: Friday, August 16, 2019 6:58 PM To: mailto:psdr@hamwan.org Subject: Re: [HamWAN PSDR] Idea for addressing HTTPS on HamWAN On 8/16/19 9:40 PM, Jake Visser wrote:
Much like HSTS; Expect-CT is starting to be deployed too (this replaces certificate pinning). 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
This will prevent users from accessing sites that are signed by a certificate that does not appear in the public transparency logs…
From reading the draft, it looks like adding a root cert will still allow over riding this. Is that not what 2.4.1 speaks of in there? I'll admit I'm not up on the newest SSL standards.
The best option – if this is truly to be used for emergency communications – is to try the proposed FCC path.
I would say we not try that. The FCC rules can be interpreted a number of different ways now, it's likely if we ask for clarification they may do so in a way making this all a violation. Right now the FCC rules are moot on encryption, the word doesn't appear in part 97 at all. -- Bryan Fields 727-409-1194 - Voice 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 _______________________________________________ PSDR mailing list mailto:PSDR@hamwan.org 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 _______________________________________________ PSDR mailing list mailto:PSDR@hamwan.org http://mail.hamwan.net/mailman/listinfo/psdr _______________________________________________ PSDR mailing list mailto:PSDR@hamwan.org http://mail.hamwan.net/mailman/listinfo/psdr _______________________________________________ PSDR mailing list mailto:PSDR@hamwan.org http://mail.hamwan.net/mailman/listinfo/psdr
On 8/17/19 3:28 AM, Cory (NQ1E) wrote:
However, web traffic to internet sites should not be your primary use-case for being on HamWAN.
This has been the hardest thing to educate people on here in Florida. This is really designed to support services, web browsing ain't the use case other than the occasional use. It's kinda funny as there's a roving dynadish here that keeps getting resold to various hams after they each discover it's not a replacement for their cable modem. :D That said we do have one club here that's replaced their clubhouse connection with hamwan. 90% of it supports remote ham radio operations, the remote satellite stations and such. The other 10% is incidental general web-browsing, and some is SSL. This is a bit of a moot point as we've been chased down to 5.6 GHz by the traffic wackers for that sector. At the end of the day, we have to face the fact that HamWAN isn't going to be useful for most potential users as they can't understand networking or IP. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
participants (9)
-
Bryan Fields -
Bryan Fields
-
Cory (NQ1E) -
Dakota Nelson -
Doug Kingston -
Jake Visser -
John C. Miller -
Nick Kartsioukas -
Steve Stroh