search

18F / pulse

How the federal .gov domain space is doing at best practices and policies.
Other
95 stars 56 forks source link

Idea: more explicitly call out certificate chain / trust issues? #585

Closed ab closed 6 years ago

ab commented 8 years ago

I'm wondering if there is some way to better indicate issues with the TLS certificate chain that is presented by servers.

For example, https://www.acquisition.gov currently only presents the leaf certificate, and no intermediate from Symantec.

https://pulse.cio.gov/https/domains/#q=acquisition.gov https://www.ssllabs.com/ssltest/analyze.html?d=www.acquisition.gov&s=52.222.43.61&latest

The B grade on SSL Labs seems overly generous given that the page will appear insecure in many browsers.

While acquisition.gov does serve an HSTS header, this is misleading, because major browsers like Chrome and Firefox will treat it as untrusted. Users who were previously served the HSTS header over a secure channel will be unable to access the page, and for new users HSTS won't have any effect because they must click through warnings first.

And if acquisition.gov were to preload HSTS as Pulse suggests, most users would be totally unable to visit the page.

Perhaps Pulse could display the trust chain problem in some way, maybe by calling it out as an issue under HSTS, or as a separate column?

konklone commented 8 years ago

Yes, our handling of incomplete chains is...incomplete. Though, it's complicated by the fact that we currently don't distinguish at the scan level between chain errors that are from using an untrusted issuer or an incomplete chain.

There is a case where we'll display a warning about an untrusted chain as it relates to potentially shutting people out via HSTS: https://github.com/18F/pulse/blob/production/static/js/https/domains.js#L185-L187

But that's only when the site doesn't yet enforce HSTS.

Pulse launched noting chain issues with a Yes* in the Uses HTTPS column, but it complicated the display too much and I axed it. So far, we've been relying on the SSL Labs grade ding to surface the issue. SSL Labs once said they'd be lowering the ding for an incomplete chain from B to C, but they don't appear to have followed through on it.

There's really no solution I like very much, to be honest. I know that @h-m-f-t is using a harsher display for chain issues in his direct reports to agencies. From my perspective, I want to push agencies to fix incomplete chains, but I also want to have Pulse focus on pushing hard on a few things well, and each thing we push agencies on is a distraction from core compliance issues.

That all said, your point about HSTS being made less effective by incomplete chains is super relevant. Do others watching this issue have opinions?

alex commented 8 years ago

Incomplete chain is basically the same as untrusted root, from a UX perspective, on something like 25% of devices (that's Android + Firefox from https://analytics.usa.gov/). I'd be in favor of penalizing incomplete chain for that reason.

On Mon, Oct 17, 2016 at 5:14 PM, Eric Mill notifications@github.com wrote:

Yes, our handling of incomplete chains is...incomplete. Though, it's complicated by the fact that we currently don't distinguish at the scan level https://github.com/dhs-ncats/pshtt/issues/25 between chain errors that are from using an untrusted issuer or an incomplete chain.

There is a case where we'll display a warning about an untrusted chain as it relates to potentially shutting people out via HSTS: https://github.com/18F/pulse/blob/production/static/js/ https/domains.js#L185-L187

But that's only when the site doesn't yet enforce HSTS.

Pulse launched noting chain issues with a Yes* in the Uses HTTPS column, but it complicated the display too much and I axed it. So far, we've been relying on the SSL Labs grade ding to surface the issue. SSL Labs once said they'd be lowering the ding for an incomplete chain from B to C, but they don't appear to have followed through on it.

There's really no solution I like very much, to be honest. I know that @h-m-f-t https://github.com/h-m-f-t is using a harsher display for chain issues in his direct reports to agencies. From my perspective, I want to push agencies to fix incomplete chains, but I also want to have Pulse focus on pushing hard on a few things well, and each thing we push agencies on is a distraction from core compliance issues.

That all said, your point about HSTS being made less effective by incomplete chains is super relevant. Do others watching this issue have opinions?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/18F/pulse/issues/585#issuecomment-254336104, or mute the thread https://github.com/notifications/unsubscribe-auth/AAADBE0GPg6ViC8Ih-eZdJN--NiqGFONks5q0-U4gaJpZM4KZFcq .

"I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) "The people's good is the highest law." -- Cicero GPG Key fingerprint: D1B3 ADC0 E023 8CA6

konklone commented 8 years ago

@alex One issue is that an untrusted root is not in and of itself a violation of M-15-13. If a site is only used by devices with agency-managed trust stores, an FPKI or DoD root is acceptable. They just need to be willing to commit to it with HSTS.

This is in tension with the fact that this approach removes the value of HSTS for users without the non-publicly-trusted root installed, especially since an HSTS policy won't be set for those users unless the domain is preloaded.

That all said, I think these are the current HTTPS compliance design goals for Pulse, in rough order of implemented importance:

  1. Give a Yes to Uses HTTPS for iad.gov. Even though they use a DoD root, they support HTTPS connections.
  2. Provide incentives for iad.gov to set an HSTS policy, which will require them to resolve any internal policy barriers to doing so.
  3. Provide incentives for sites with incomplete certificate chains to fix them.

Pulse definitely does 1., it might contribute to 2., and doesn't really do much for 3. besides display the B grade from SSL Labs. I'm up for improving how it accomplishes 3., but ideally it would come without harming 1. or 2..

This is, to some extent, me prioritizing overall compliance effectiveness -- which I think improves the security of client connections government-wide -- over a specific common configuration error that reduces the security of client connections to that configuration.

One easy way to improve the situation is to fix https://github.com/dhs-ncats/pshtt/issues/25, so that incomplete chain errors can get called out without affecting calculations around untrusted roots. I've spent some time trying to remove sslyze as a dependency from pshtt, but working with the underlying Python ssl library and the inability for requests to use a different backend turned out to be a huge PITA.