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

41–50 of 132 posts

Re: Living with HTTPS

#41

Post by justhw »

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 are concerned about the warnnings that users see, just call your static files in such a format.

'//www.your-cdn.com/image.jpg'

In other words don't specify http or https in the url, just do '//your-url.com/new.js'

Re: Living with HTTPS

#43

Post by Erwin »

agwa wrote: post #24
rmc wrote: post #17

Earlier quoted context omitted.

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/I…

A certificate can also have a number of alternate names, which providers call a Unified certificate -- UCC. The nice thing about that is that you can add/remove names after you've bought the certificate without having to go through the process.

I haven't tried this in practice though, but this might be useful if you want to provide a bunch of client.yourdomain.com secure subdomains from the same IP address. Only downside is that the organization name will be the same.

Re: Living with HTTPS

#44

Post by abraham »

rdl wrote: post #16

This was by a wide margin my favorite talk at HOPE this year. (and a great advertisement for using Chrome in secure settings where you need a web browser) The irony of Google being one of the main http-only JS resources for a long time was kind of amusing, though.

What do you mean by "Google being one of the main http-only JS resources"?

Re: Living with HTTPS

#45

Post by flatline3 »

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…

> We sometimes have certificate issues with our proxy server at my workplace ...

This is the problem.

> ... and it makes Chrome practically unusable when they happen

This is not the problem.

Re: Living with HTTPS

#46

Post by agwa »

Erwin wrote: post #43
agwa wrote: post #24

Earlier quoted context omitted.

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/I…

A certificate can also have a number of alternate names, which providers call a Unified certificate -- UCC. The nice thing about that is that you can add/remove names after you've bought the certificate without having to go through the process. I haven't tried this in practice though, but this might be useful if you want to provide a bunch of client.yourdomain.com secure subdomains from the same IP address. Only down…

Also more expensive than vanilla single-name certs :-(

That's the one downside of this HTTPS-everywhere movement - we're beholden more than ever to the certificate authority cartel.

Re: Living with HTTPS

#47

Post by pwaring »

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.

"Certificates are only valid for a single domain, after all"

Actually that's not the case, you can get single certificates which cover different domains, using the Subject Alternative Name field.

Re: Living with HTTPS

#48

Post by tptacek »

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…

It's very straightforward for a proxy to have its own CA=YES certificate and mint/sign certs for every HTTPS site the proxy sees on the fly. If you have a corporate proxy that is intercepting HTTPS traffic, that is what it should be doing.

Then, the proxy makes its certificate available to users, you download it, and add it to your CA certs via the UI that browsers provide for that; HTTPS magically appears to work again.

Re: Living with HTTPS

#49

Post by tptacek »

peterwwillis wrote: post #35
clarkevans wrote: post #25

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.

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.

Re: Living with HTTPS

#50

Post by rdl »

abraham wrote: post #44
rdl wrote: post #16

This was by a wide margin my favorite talk at HOPE this year. (and a great advertisement for using Chrome in secure settings where you need a web browser) The irony of Google being one of the main http-only JS resources for a long time was kind of amusing, though.

What do you mean by "Google being one of the main http-only JS resources"?

Adsense.

Also I think GA was http only at some point.

Post reply on HN