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

101–110 of 132 posts

Re: Living with HTTPS

#101

Post by harshreality »

rabidsnail wrote: post #32
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…

It's actually kind of a pain to enable HSTS because it makes you fix all the places where you're downgrading to HTTP. You should definitely do it if you care whether your users' sessions get hijacked, but it's not _just_ flipping a switch.

Pages with http://yoursite links work seamlessly. The browser will access those via https when you click. As long as the SSL version of your site is serving the same resources, there's no problem.

Re: Living with HTTPS

#102

Post by harshreality »

DannoHung wrote: post #27

Please for the love of god, if you're working at google and read this: Add a deeply set option to FORCIBLY enable that button in all situations where it might appear. We sometimes have certificate issues with our proxy server at my workplace and it makes Chrome practically unusable when they happen. I know what I'm doing. I'll reset the option when the underlying issue is resolved, and overall it's a great feature fo…

You can remove HSTS on a per-domain basis using

chrome://net-internals/#hsts

Are you looking for something else?

Re: Living with HTTPS

#103

Post by LeafStorm »

icebraining wrote: post #78
chime wrote: post #33

Earlier quoted context omitted.

If clearing the browser cache/cookies makes the browser forget about STS for each domain, then MITM attacker gets a lot more chances to intercept and attack. I don't have stats on how often average users clear their browsers but it is a fairly common troubleshooting step so most people are aware of it. If clearing the browser cache/cookies does not make the browser forget about STS for each domain, then we got anothe…

The whole point of tracking cookies is to maintain some identifier. With STS you only get 1 bit, how do you identify them? All users who have visited the site since (now - STS expiration length) look the same.

On the other hand, if the Chinese government finds out you have an HSTS flag for https://www.youversion.com/ or some such...

Re: Living with HTTPS

#104

Post by rondon1 »

codeka wrote: post #97
dekz wrote: post #81

Earlier quoted context omitted.

So the proxy server acts as a forced man in the middle? This has to be one of the most atrocious things I have ever experienced. Forcing a man in the middle is insane especially in a large company where there may well be a lack in competency. HTTPS shouldn't magically appear to 'work' again, considering it is completely broken when a forced mitm is introduced.

This is far more common than you might expect. You just need to push you're company's internal CA to all your client computers, and bam , MITM for everything!

Yes enterprise customers want to decrypt and inspect all traffic, for legitimate and sometimes sketchy reasons.

Re: Living with HTTPS

#105

Post by [deleted] »

harshreality wrote: post #101
rabidsnail wrote: post #32

Earlier quoted context omitted.

It's actually kind of a pain to enable HSTS because it makes you fix all the places where you're downgrading to HTTP. You should definitely do it if you care whether your users' sessions get hijacked, but it's not _just_ flipping a switch.

Pages with http://yoursite links work seamlessly. The browser will access those via https when you click. As long as the SSL version of your site is serving the same resources, there's no problem.

[deleted]

Re: Living with HTTPS

#106

Post by emmelaich »

timr wrote: post #75

Honest question, for those who have done it: what are the downsides of allowing your whole site to be accessed via SSL? Obviously, you need to be a bit more diligent about making asset urls protocol-relative (which can be a PITA across a large, dynamically generated site), but are there any other gotchas? Server load? Reduced cache-ability?

By protocol relative, are you referring to the // urls?

(http://paulirish.com/2010/the-protocol-relative-url/)

Because they wound't be so PITAish would they?

Re: Living with HTTPS

#107

Post by justinschuh »

harshreality wrote: post #102
DannoHung wrote: post #27

Please for the love of god, if you're working at google and read this: Add a deeply set option to FORCIBLY enable that button in all situations where it might appear. We sometimes have certificate issues with our proxy server at my workplace and it makes Chrome practically unusable when they happen. I know what I'm doing. I'll reset the option when the underlying issue is resolved, and overall it's a great feature fo…

You can remove HSTS on a per-domain basis using chrome://net-internals/#hsts Are you looking for something else?

You can't remove the preloaded ones, which is really how it should be.

Re: Living with HTTPS

#108

Post by justinschuh »

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 standard very explicitly states that Chrome's behavior is correct:

   When connecting to a Known HSTS Server, the UA MUST terminate the
   connection with no user recourse if there are any errors (e.g.
   certificate errors), whether "warning" or "fatal" or any other error
   level, with the underlying secure transport.
http://tools.ietf.org/html/draft-hodges-strict-transport-sec...

Re: Living with HTTPS

#110

Post by moxie »

justauser wrote: post #96
NateLawson wrote: post #64

Earlier quoted context omitted.

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…

I see Moxie is one of the authors on the draft. Is this an outgrowth/pivot of Convergence?

The way I see the relationship between Convergence and TACK is that Convergence is trying to provide trust agility for when we need to trust third parties, while TACK is trying to reduce the amount that we even need to trust a third party at all.

I think the first problem gets considerably easier to solve once the latter is in place, and there's a lot we could do with Convergence-like systems that would make them more deployable if TACK is adopted.

In the short term, however, TACK stands on its own, and we hope it's a fairly uncontroversial proposal that will be easy to integrate into the ecosystem.

Post reply on HN