[HamWAN PSDR] Idea for addressing HTTPS on HamWAN

[Jake Visser]

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 at bryanfields.net>
Sent: Friday, August 16, 2019 6:28 PM
To: psdr at hamwan.org<mailto:psdr at 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 at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.hamwan.net/pipermail/psdr/attachments/20190817/07aee07b/attachment.html>