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

21–30 of 132 posts

Re: Living with HTTPS

#21

Post by bonzoesc »

e1ven wrote: post #8
jenseng wrote: post #5

The author seems to gloss over the importance of browser built-in HSTS lists. If you're just relying on a response header to tell the browser to use HTTPS, aren't you still vulnerable? Isn't that the same fundamental problem with redirecting to HTTPS via Location headers? In other words, a MITM could downgrade any HTTPS traffic and simply remove that STS header. The browser would be none the wiser.

The STS header has an expiration date on it. Let's assume you have it set to 1 year. If user A visits the site in March, receives the header, uses the site for a while. In May, the site/user's DNS/whatever is hijacked. Users are sent to a dummy site, which does not set the header. The dummy site is over HTTP. The next day, the user tries to go to the site. Because it is not over HTTPS, the browser refuses to load the…

    strict-transport-security:max-age=2592000; includeSubDomains
It has a maximum age, not an expiration date. If I visit gmail today, that STS header will expire a month from now[1].

If I visit again tomorrow, the browser-cached version of that header will be updated with a new expiration date, and expire a month from tomorrow, not now.

1: http://www.wolframalpha.com/input/?i=2592000%20seconds

edit: I think we're agreeing.

Re: Living with HTTPS

#22

Post by [deleted] »

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…

[deleted]

Re: Living with HTTPS

#23

Post by moonboots »

yorhel wrote: post #15

Somewhat related question: It's fairly common for sites to have static files (images/css) served on a different (sub)domain. What are you supposed to do when the html content is being served on HTTPS? Should the static files be on HTTPS as well? If so, wouldn't it need a different certificate? Certificates are only valid for a single domain, after all.

If you don't want to pay a premium for a wildcard certificate, you could just get another certificate for the static subdomain. You can get an unlimited number of free, single subdomain certificates from StartSSL.

Re: Living with HTTPS

#24

Post by agwa »

rmc wrote: post #17
yorhel wrote: post #15

Somewhat related question: It's fairly common for sites to have static files (images/css) served on a different (sub)domain. What are you supposed to do when the html content is being served on HTTPS? Should the static files be on HTTPS as well? If so, wouldn't it need a different certificate? Certificates are only valid for a single domain, after all.

You can get SSL certs that are valid for wild card subdomains, e.g. *.example.com

Wildcard certs tend to be very expensive. If you only need two domains it's probably more cost-effective to just buy two certs.

Edit: a downside of using separate certs is that you'll need to serve the respective sites from separate IP addresses, or rely on SNI [1] which isn't supported in older browsers. But if the use case is a separate domain for serving static files, that's probably hosted on a different server/IP address anyways, right?

[1] http://en.wikipedia.org/wiki/Server_Name_Indication

Re: Living with HTTPS

#25

Post by clarkevans »

I'm wondering if there could be an equivalent DNS entry that might help signal a site should only be accessed via SSL? Then you could possibly protect against initial access as well as returning users.

Re: Living with HTTPS

#26

Post by harshreality »

isaacaggrey wrote: post #3

For users, HTTPS Everywhere is a must: https://www.eff.org/https-everywhere Also, by using DuckDuckGo [1] over HTTPS you get the same ruleset in HTTPS Everywhere [2] even if you don't have the extension installed. [1] https://duckduckgo.com/ [2] http://www.gabrielweinberg.com/blog/2010/09/duckduckgo-imple...

The chrome extension at least seems to break a lot of sites. They're not kidding when they say it's alpha.

Pages include resources from https-everywhere'd domains and for whatever reason (mostly that the ssl versions of those resource urls aren't serving the same resources, or have broken certs) those resources fail to load. Within an hour of using it I'd seen it break 3 or 4 sites, so it got disabled.

You can manually disable it for individual sites, if you recognize that it's the problem, but if some minor resource fails to load it might not be obvious.

Re: Living with HTTPS

#27

Post by DannoHung »

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 for the browser, but I need to have the ability to be responsible for myself.

Re: Living with HTTPS

#28

Post by Flimm »

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…

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

Re: Living with HTTPS

#29

Post by moonboots »

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…

A solution going forward to contain 3rd party javascript is HTML5 sandbox iframe. This allows declaring a whitelist of permissions 3rd party code should be granted. Only about 40% of browsers support this feature [1]. For unsupported browsers, the external javascript continues working without the security guarantees, so it's no worse than the situation now.

[1] http://caniuse.com/#feat=iframe-sandbox

Re: Living with HTTPS

#30

Post by agl »

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…

The bypass button only disappears for HSTS sites. Do you have a proxy server that's intercepting these connections and has a broken certificate?

You can disable all certificate checking with --ignore-certificate-errors but it is as bad as it sounds.

Rather, to correctly support MITM proxies you should install their CA certificate locally.

Post reply on HN