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

[ab]

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]

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]

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 cisagov/pshtt#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
#585 (comment), 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]

@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 cisagov/pshtt#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.