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

Living with HTTPS

imperialviolet.org

Post reply on HN
Print view View original

61–70 of 132 posts

Re: Living with HTTPS

#61

Post by Flimm »

jarek wrote: post #59
Flimm wrote: post #28

Earlier quoted context omitted.

Or fix the certificate issues. Don't train the staff to be blind to security warnings.

How exactly does "I know what I'm doing. I'll reset the option when the underlying issue is resolved, and overall it's a great feature for the browser, but I need to have the ability to be responsible for myself." become "train the staff to be blind to security warnings"?

If you know what you're doing, you'd know how to get around this limitation, with the --ignore-certificate-errors option for example. Any knowledgeable front-end or back-end developer would know how to find this out by doing a Google search. As long as you don't train the rest of the staff to do the same, that's fine. Now, why isn't the IT department fixing this security and usability problem?

Re: Living with HTTPS

#62

Post by tptacek »

jarek wrote: post #59
Flimm wrote: post #28

Earlier quoted context omitted.

Or fix the certificate issues. Don't train the staff to be blind to security warnings.

How exactly does "I know what I'm doing. I'll reset the option when the underlying issue is resolved, and overall it's a great feature for the browser, but I need to have the ability to be responsible for myself." become "train the staff to be blind to security warnings"?

If you know what you're doing, get the CA=YES cert from your proxy and install it in your browser.

Re: Living with HTTPS

#63

Post by tptacek »

sadpluto wrote: post #58
agl wrote: post #31

Earlier quoted context omitted.

We can't do a blocking DNS lookup other than for A/AAAA records. About 5% of Chrome users cannot resolve TXT records because the network is filtering the DNS requests. (i.e. we know that the network is up and we're asking about a DNS name that we known exists, but we get a timeout.)

In [1] you showed us how to authenticate via DNSSEC HTTPS in Chrome. If I understand correctly this involves a lookup of a TYPE257 record. Given that only 5% can resolve TXT records, do you know what % of Chrome users can then resolve TYPE257 records? Digressing a bit further, wouldn't you say that even if HSTS is enabled and registered in the all the browsers' built-in list, you still have the problem of unencrypted…

No. The whole idea of HSTS is that you can never trust the DNS; you assume that's the most likely way an attacker is going to MITM her victims. HSTS tells the browser to remember that from that point on, all connections to SERVER.NAME have to happen under a TLS session with a valid cert.

Re: Living with HTTPS

#64

Post by NateLawson »

tptacek wrote: post #4

This is pretty great. I guess he gave this talk at HOPE, but it's laser scoped to startups, down to the order in which he gives the advice: * Enable HSTS * Don't link to HTTP:// javascript resources from HTTPS pages * Set the secure flag on cookies Very few of the sites we test enable HSTS. But it's easy to do; it's just an extra header you set. The only quibble I might have is the fatalism he has about mixed-securit…

All of these are good recommendations.

Another technology to start preparing for is TACK. It allows you, the server owner, to control browser pinning of your certs while maintaining CA mobility. This gives you the control over your security that Google has over Gmail via Chrome cert pinning without having to issue a new browser build every time you change CAs.

One way to think of it is like a domain transfer lock but with cryptography. You control how you unlock your pin to allow mobility to a new CA by sticking a signed file on your SSL server.

http://tack.io/

[Disclosure: one of the authors of TACK is a former co-worker.]

Re: Living with HTTPS

#65

Post by philjohn »

tptacek wrote: post #4

This is pretty great. I guess he gave this talk at HOPE, but it's laser scoped to startups, down to the order in which he gives the advice: * Enable HSTS * Don't link to HTTP:// javascript resources from HTTPS pages * Set the secure flag on cookies Very few of the sites we test enable HSTS. But it's easy to do; it's just an extra header you set. The only quibble I might have is the fatalism he has about mixed-securit…

if you need an absolute URI for any assets, then just use:

//www.example.com/path/to/asset.js

this will then use the same transport as the containing page uses.

Re: Living with HTTPS

#66

Post by konstruktor »

tptacek wrote: post #56
konstruktor wrote: post #53

Earlier quoted context omitted.

The latter is just as bad. Opinionated software, i.e. making things that are usually a bad choice hard, is a good thing. Making possible things deliberately impossible for the victims of other people's bad decision making is arrogant. So some idiot CIO chose to make https mandatory but their staff can't get it configured properly. I am sure the non-IT user's boss will be happy that, instead of, say, closing that one…

Random enterprises will always be breaking some part of the HTTP stack. It's not reasonable to degrade everyone's security, even the majority of people who don't have unnecessary breakage inflicted on them, just to accommodate those enterprises. There is a clean solution to this problem: the proxies should serve as just-in-time CAs for the traffic they proxy. The big proxy products all do that. This simply isn't Chro…

Do you realize that it's not the abstract concept of an enterprise using a browser, but a human being? Which, usually, is not the person administering the server. I'm all for nudging people to change their own behaviour to the better, but this is driving your principles home on the back of the user.

Considering your use of the word "breakage": DannoHung is talking about a button that is actively being disabled in certain situations, not something bad being enabled. This is extra code in a security critical part of the browser. Thus, we can assume that there were meetings that discussed this "feature" and its implications, the actual coding, code reviews and QA, adding up to quite a bit of opportunity cost. That begs the question: Would this time have been better spent on something that adds more security?

Disabling manual overrides may seem like a good idea, but it can go horribly wrong. http://en.wikipedia.org/wiki/Lufthansa_Flight_2904

Re: Living with HTTPS

#67

Post by tptacek »

konstruktor wrote: post #66
tptacek wrote: post #56

Earlier quoted context omitted.

Random enterprises will always be breaking some part of the HTTP stack. It's not reasonable to degrade everyone's security, even the majority of people who don't have unnecessary breakage inflicted on them, just to accommodate those enterprises. There is a clean solution to this problem: the proxies should serve as just-in-time CAs for the traffic they proxy. The big proxy products all do that. This simply isn't Chro…

Do you realize that it's not the abstract concept of an enterprise using a browser, but a human being? Which, usually, is not the person administering the server. I'm all for nudging people to change their own behaviour to the better, but this is driving your principles home on the back of the user. Considering your use of the word "breakage": DannoHung is talking about a button that is actively being disabled in cer…

The button he's asking for is "disable TLS security".

If he wants to disable TLS security, there's a right way to do it: by installing the proxy's cert.

If you read 'agl's talk, you'd see that the reason the button is hidden is that it is one of the Internet's great security flaws: a workflow embedded into most browsers that demands users to learn to disable TLS security.

So, I find this argument you're making to be more or less entirely bankrupt.

Re: Living with HTTPS

#68

Post by zobzu »

What I take out of this, beside things I knew of already (and most others as well) is:

* Chrome wants to FORCE you to buy an SSL certificate.

* The guy suggest getting one from StartSSL BUT those are crap for 2 reasons: you can only have ONE domain, else you have to pay. The TOS are horrible.

So, dear imperialviolet, if you want me to use certificates that your company trusts (and by extension, your users), get up with it and make Google provide free, unlimited SSL certificates.

Til then, no dice.

Re: Living with HTTPS

#69

Post by fijal »

For what is worth Libya owned a trusted CA (maybe still does), which means that MITM would happily work, because they can transfer all the certs to their own authority. I don't personally see how this is more secure than my self-signed certificate, which generates a warning that's these days very hard to avoid (even if I do know that the cert is fine)

Re: Living with HTTPS

#70

Post by peterwwillis »

tptacek wrote: post #49
peterwwillis wrote: post #35

Earlier quoted context omitted.

DNSSEC could allow this to work, if the connection between the client and a DNSSEC-enabled recursive resolver were secure. But if you're on the LAN of the client (for example, a wireless network) you can spoof every DNS response and the client is boned.

... at the cost a myriad of other annoyances, breakages, and potential insecurities after DNSSEC is deployed. Deploying DNSSEC to help with the problem that HSTS is trying to solve is like deploying Homer Simpson's automatic hammer to pin an announcement to a bulletin board.

It's still one possible solution to the problem. If one's windows dns client were a DNSSEC-validating stub resolver[1], and you believe that in the future we will come to a point where network admins stop fucking with DNS traffic for no good reason, they could authenticate information from the website's dns on first-visit and avoid HSTS's pitfall. Note that I never said this was going to be practical :)

[1] https://www.internetsociety.org/deploy360/resources/dnssec-t...

Post reply on HN