Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Automatic HTTPS Enforcement for New Executive Branch .gov Domains

cio.gov

Post reply on HN
Print view View original

31–40 of 82 posts

Re: Automatic HTTPS Enforcement for New Executive Branch .gov Domains

#31

Post by xenophonf »

cakeface wrote: post #14

What are the odds that the private keys for all of the .gov domains are also sent to the NSA? I guess if you are worried about another nation spying on your traffic you would be fine. I would expect that all of this traffic is decryptable by NSA though.

What are you getting at? As far as I know, OMB doesn't require key escrow, so it almost certainly doesn't happen at scale. I'd imagine that if an intelligence service asked an agency for keymat, they'd happily provide it. I know that I wouldn't have a problem with someone from old St. Elizabeths Hospital or Fort Meade or Crystal City asking me for stuff, especially since the order to co-ooperate with DHS or NSA or the Pentagon would come through the agency's chain of command.

That said, DHS runs an intrusion prevention system called EINSTEIN, whose mission is to protect all federal civilian computer networks:

https://en.wikipedia.org/wiki/Einstein_(US-CERT_program)

Using EINSTEIN _is_ mandated by OMB, so if you're worried about the U.S. federal government snooping on your communications with the U.S. federal government, I don't know what to tell you.

Re: Automatic HTTPS Enforcement for New Executive Branch .gov Domains

#32

Post by pfg »

Godel_unicode wrote: post #29
konklone wrote: post #25

Earlier quoted context omitted.

If there's an issue with certificate validation, the attack surface is already open.

You've forgotten that security includes availability, in addition to confidentiality and integrity. Interesting design choice for the entity which runs the emergency broadcasting system. You're saying you'd prefer for e.g. NOAA to not be able to issue tornado warnings in order to ensure nobody can fake a tornado warning.

I think what konklone was getting at is that any scenario that allows an attacker to trigger a certificate warning (and effectively taking down the service) would also allow them to take down the service through other means. Do you have a scenario in mind that doesn't require either a MitM (who could just as well block the service) or a compromised client/server (which would allow the attacker to block access either way)?

Re: Automatic HTTPS Enforcement for New Executive Branch .gov Domains

#33

Post by tedunangst »

t0mas88 wrote: post #3

As a practical question: what is the expected capacity of the preload stores of browsers? Hundreds of thousands, millions or much more domains? Because at some point it seems like everyone with moderately high security requirements may want to have their certificates pinned / preloaded.

My browser's disk footprint is already over 100MB. What's another X MB?

The ironic thing is we're reinventing the CA system, only now each browser is its own authority, exactly the problem the CA system was trying to solve.

Re: Automatic HTTPS Enforcement for New Executive Branch .gov Domains

#34

Post by tedunangst »

pfg wrote: post #32
Godel_unicode wrote: post #29

Earlier quoted context omitted.

You've forgotten that security includes availability, in addition to confidentiality and integrity. Interesting design choice for the entity which runs the emergency broadcasting system. You're saying you'd prefer for e.g. NOAA to not be able to issue tornado warnings in order to ensure nobody can fake a tornado warning.

I think what konklone was getting at is that any scenario that allows an attacker to trigger a certificate warning (and effectively taking down the service) would also allow them to take down the service through other means. Do you have a scenario in mind that doesn't require either a MitM (who could just as well block the service) or a compromised client/server (which would allow the attacker to block access either…

Well, it doesn't have to be an attack per se. Maybe the client's clock is wrong, which actually happens a lot. Or admin error replacing the cert on the server. There are of course lots of ways admin error can take down a server, but https adds some fun possibilities that are easier to trigger and harder to recover from.

Re: Automatic HTTPS Enforcement for New Executive Branch .gov Domains

#35

Post by Godel_unicode »

pfg wrote: post #32
Godel_unicode wrote: post #29

Earlier quoted context omitted.

You've forgotten that security includes availability, in addition to confidentiality and integrity. Interesting design choice for the entity which runs the emergency broadcasting system. You're saying you'd prefer for e.g. NOAA to not be able to issue tornado warnings in order to ensure nobody can fake a tornado warning.

I think what konklone was getting at is that any scenario that allows an attacker to trigger a certificate warning (and effectively taking down the service) would also allow them to take down the service through other means. Do you have a scenario in mind that doesn't require either a MitM (who could just as well block the service) or a compromised client/server (which would allow the attacker to block access either…

You might want to re-read my post more carefully, there is not necessarily an attacker per-se in an availability incident (although there certainly could be. Depends on how evil one wants to think.).

Backhoe eats the fiber to the ocsp responder and CRL distribution point, CRLs timeout after 24 hours.

Boom, as the kids are saying.

Re: Automatic HTTPS Enforcement for New Executive Branch .gov Domains

#36

Post by dsp1234 »

pfg wrote: post #32
Godel_unicode wrote: post #29

Earlier quoted context omitted.

You've forgotten that security includes availability, in addition to confidentiality and integrity. Interesting design choice for the entity which runs the emergency broadcasting system. You're saying you'd prefer for e.g. NOAA to not be able to issue tornado warnings in order to ensure nobody can fake a tornado warning.

I think what konklone was getting at is that any scenario that allows an attacker to trigger a certificate warning (and effectively taking down the service) would also allow them to take down the service through other means. Do you have a scenario in mind that doesn't require either a MitM (who could just as well block the service) or a compromised client/server (which would allow the attacker to block access either…

This response implies that it the reduced available need be malicious, it could be non-intentional as well.

ex:

During an emergency I connect to public wifi because mine is not working. That wifi has a MITM proxy installed by the owner (because they want to server ads over https, it's a developer's wifi and they were testing with something like charles proxy, etc). This page is now unavailable during an emergency. Thus lack of availability without malicious intent.

The general assumption for HSTS is that, in all cases, it's better to be unavailable than have the possibility of compromise. I'm unsure if that's the case for critical services in times of need.

Re: Automatic HTTPS Enforcement for New Executive Branch .gov Domains

#37

Post by Godel_unicode »

tedunangst wrote: post #34
pfg wrote: post #32

Earlier quoted context omitted.

I think what konklone was getting at is that any scenario that allows an attacker to trigger a certificate warning (and effectively taking down the service) would also allow them to take down the service through other means. Do you have a scenario in mind that doesn't require either a MitM (who could just as well block the service) or a compromised client/server (which would allow the attacker to block access either…

Well, it doesn't have to be an attack per se. Maybe the client's clock is wrong, which actually happens a lot. Or admin error replacing the cert on the server. There are of course lots of ways admin error can take down a server, but https adds some fun possibilities that are easier to trigger and harder to recover from.

Bonus points for client clock error. If I had a nickel for every time...

The best is when it's a timezone issue and the distant end responds with "I have 0 drift, must be a problem on your end". Crypto is hard, time is hard. Crypto which relies on time...

Re: Automatic HTTPS Enforcement for New Executive Branch .gov Domains

#38

Post by scrollaway »

konklone wrote: post #2

Co-author of the post here, happy to answer questions. =) This is a GSA initiative, not an 18F initiative. But 18F has a recent post detailing executive branch progress on HTTPS that may also be relevant: https://18f.gsa.gov/2017/01/04/tracking-the-us-governments-p...

The blog post is unclear. On a technical level (on the preload list), is the enforcement at the TLD level or is it just a legal requirement to submit all .gov domain names to the preload list? If the latter, any plan to move to the former?

Re: Automatic HTTPS Enforcement for New Executive Branch .gov Domains

#39

Post by nitrogen »

foota wrote: post #19
t0mas88 wrote: post #3

As a practical question: what is the expected capacity of the preload stores of browsers? Hundreds of thousands, millions or much more domains? Because at some point it seems like everyone with moderately high security requirements may want to have their certificates pinned / preloaded.

Seems like you could use a bloom filter to store whether a domain has a pinned cert, and then use an api provided by the browser to remotely fetch the pinned cert. This has privacy implications, but does step around the storage. Chrome does something similar for CRL, but bloom filters fit that use case better.

IIRC DuckDuckGo might do something like that for search suggestions. For slightly improved privacy, lots of unrelated hosts can be grouped into blocks (maybe grouped by probability of access to make it harder to infer which domain from the block is the likely target).

Re: Automatic HTTPS Enforcement for New Executive Branch .gov Domains

#40

Post by pfg »

Godel_unicode wrote: post #35
pfg wrote: post #32

Earlier quoted context omitted.

I think what konklone was getting at is that any scenario that allows an attacker to trigger a certificate warning (and effectively taking down the service) would also allow them to take down the service through other means. Do you have a scenario in mind that doesn't require either a MitM (who could just as well block the service) or a compromised client/server (which would allow the attacker to block access either…

You might want to re-read my post more carefully, there is not necessarily an attacker per-se in an availability incident (although there certainly could be. Depends on how evil one wants to think.). Backhoe eats the fiber to the ocsp responder and CRL distribution point, CRLs timeout after 24 hours. Boom, as the kids are saying.

> You might want to re-read my post more carefully, there is not necessarily an attacker per-se in an availability incident (although there certainly could be. Depends on how evil one wants to think.).

Well, that was the context of this thread. Both the OP and konklone are talking about attack surface. If you want to talk about how running a service via TLS and using HSTS makes HA harder, that's a different discussion.

> Backhoe eats the fiber to the ocsp responder and CRL distribution point, CRLs timeout after 24 hours.

OCSP and CRL is soft-fail by default in all browser I'm aware of. The server is also in control of it via OCSP Stapling, so it has all the tools it needs to keep the server available, assuming proper configuration and monitoring (which is true for a HTTP service as well).

Post reply on HN