New Threat To HTTPS?

[Rob Seastrom]

> On Mar 18, 2017, at 8:11 PM, Richard Demaret <ric.demaret at gmail.com> wrote:
> 
> .
> Greetings:
> 
> Is this a new threat to HTTPS?
> 
> Article: HTTPS interception weakens HTTPS security.
> 
> https://www.us-cert.gov/ncas/alerts/TA17-075A
> 
> 
> What do you think this means for the average end user?

It means zilch to you at home.  This is a problem space that is limited to agencies and corporations that have decided (for whatever reasons, all of which are out of scope here) that they want to "see inside" their users' https:// traffic and have taken steps to weaken https on their employees' and contractors' computers to accomplish this.

Pete alluded in a separate reply as to how this might be done.  I'll provide some more detail.  A full discussion of how PKI and browser certs (and DNSSEC!) work might be a good AMRAD talk, but is a little long for this mailing list.

Briefly, from a protocol perspective, https will work without authenticating the far end, but you'll get a big red warning in your browser ( look here for an example http://webmasters.stackexchange.com/questions/57048/would-a-self-signed-certificate-impact-my-site-for-search-engines but you've definitely seen these before).

In order for https to "work normally" and give you a gray or green padlock, the certificate that the server end presents must be cryptographically signed (directly or indirectly) by someone that you trust.  How do you know that you trust them?  The public part of their public/private certificate pair comes with your computer or your web browser and they're vetted by the computer or browser vendor - these are known as "trust anchors".  On the freshly-installed Mac running 10.12 "Sierra" sitting next to me there are 169 of these [1].  If a public certificate half that is presented by a web site as part of the https handshake matches their hostname and is signed by a private key that corresponds to the list of public keys that came with your computer, then effectively that certificate authority is "vouching" for the identity of that web site, and you get a gray or green padlock and the site loads with no error.

The way that your company/agency/whatever does a man-in-the-middle attack is that they issue a 170th trust anchor and install the public half in your computer and say "trust this".  Then they give the public and private halves to a box that sits between you and the Internet and creates new certificates claiming to be any web site, on demand.  That way they can inspect your traffic in real time, and then make another outbound encrypted connection to wherever you were originally going.

While the employer obviously has the right to know what you're up to at work, on computers that are issued by them, there is information that is transmitted as part of the https connection that is none of their business.  For instance, "Rob spent 10 minutes on his credit union web site today when he should have been working" is reasonable for my employer to know.  "Rob uses this username and password to log into the credit union web site" is not reasonable for them to know.  But there's no way to separate those out.

Moreover, a trust anchor certificate pair is an extremely powerful thing (absolute power is based on the size of the user community that trusts it, naturally), and the commercial certificate authorities take extraordinary care to guard against them being accidentally divulged.  Your employer in most cases does not have the skills or the resources to protect it adequately.

The gray areas start getting a whole lot grayer when one looks at things like BYOD and "it's fine to take your computer home and do ordinary computer stuff on it" policies.

All in all, I think these schemes are a net minus.  Reasonable people may disagree.  I'm glad I don't work for them.

But I digress.  If you don't have an added trust anchor from your employer to facilitate use of an https interception product, then this alert doesn't apply to you.

-r


[1] security dump-keychain /System/Library/Keychains/SystemRootCertificates.keychain | grep "class: 0x80001000" | wc -l