Hacker News Reader

Comment by PaulHoule | Hacker News Reader

I hope SSL is a fad.

I haven't once seen an intranet renew it's SSL certificate on time so it means at least once a year there will be a period of a week to six months that you have to click through a warning message.

Google switched the search to SSL and now nobody gets referrers for Google searches anymore.

When Google switched to SSL now I have trouble when I connect to public WiFi networks that want you to agree to something or log in to use the network -- it used to be you got redirected but now search just breaks without a sensible warning message.

View on HN

For internal resources, there's no good reason at all to use browser-CA certificates. Just set up your own internal CA (it's like 3 openssl commands), add its certificate to your trust stores, and sign your own certificates.

If you know you're only ever going to have a couple-three boxes using SSL, you can also just use self-signed certificates and a static whitelist. Self-signed certificates don't work at all on the public Internet, but they're just fine for internal resources, as long as you can somehow pin them.

> Self-signed certificates don't work at all on the public Internet, but they're just fine for internal resources, as long as you can somehow pin them.

Yes self-signed certificates don't work for web servers/browsers but they work great for *aaS providers.

A lot of DBaaS providers sign their server SSL certificates with an internal self-signed CA (ex: AWS for MySQL RDS[1]). You just need to retrieve the CA certificate over a secure channel (ex: HTTPS) and save it along with the rest of the DB config for your app (user/pass/host/port) so it's pinned.

This is arguably better than using the browser-CA chain as the service provider itself would need to be complicit in compromising it (vs a malicious trusted root issuing a fraudulent trusted cert for the remote server).

[1]: http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_M...

Just a nit: those aren't self-signed certificates; those are certificates signed by an internal CA. A self-signed certificate is a standalone entity.

> add its certificate to your trust stores

If only that was so simple and all software used a common store... Without exceptions like java apps, apps with hardcoded ca_path, scripts which call curl with hardcoded ca_path, etc. On top of that are websockets in FF which will just fail rather than notify you about untrusted certificates. After experiencing that first-hand for a while, I wouldn't recommend this idea. It's the second greatest annoyance after enterprise web proxies.

> add its certificate to your trust stores

I wouldn't install a company CA certificate on my Mac. It would theoretically allow the company to intercept all my SSL connections. I'd rather validate SSL certs for all the intranet servers manually.

We're talking about server-to-server connectivity here.

Huh? The top level comment said something about Google search using SSL and "clicking through certificate warnings" which doesn't sound like server-to-server connectivity to me.

If you're worried about your employer performing man in the middle attacks to read your data, you might be working at the wrong company.

If you blindly trust anybody, you clearly don't value your privacy as much as I do.

You don't really mean self-signed, do you? I'm a doctor. Here's my diploma. I created and signed it myself. But trust me, I really am a doctor. I hope you really meant that you use an internal CA that issues certs and that you trust that CA instead.

I mean self-signed, if you pin the certs. I also mentioned internal CAs.

Self-signed certs work for internal infrastructure because you control the full chain of trust. One server issues the "diploma" and the other checks it, but they're both your servers, so the trust is predetermined.

Internal CA is more about expediency than anything else. It's just easier to manage trust between a lot of servers that way than by manually exchanging self-signed certs across all the permutations.

So you're angry at google because by them adding security, you now get warned about insecure content rather than being immediately redirected to a site without your choice because your content has been hijacked?

This right here is why security will never be mainstream, because consumers value convenience over the ability for their browser not to run arbitrary code.

> This right here is why security will never be mainstream, because consumers value convenience over the ability for their browser not to run arbitrary code.

You say that as if it's a bad a thing.

Google switched the search to SSL and now nobody gets referrers for Google searches anymore.

You're barking at the wrong tree. Google purposely killed referrers using a intermediate page. If you see this[1] answer on webmasters.SE, they use make the browser pass through a /url redirection page that doesn't have the keywords in the URL. This works in both HTTP and HTTPS.

[1] http://webmasters.stackexchange.com/a/47027

I think the grandparent is referencing the fact that Referer headers are not propagated from HTTPS sites to HTTP sites. The rationale was that the HTTPS site might have a secret or otherwise sensitive URL.

This is obviously a tremendously stupid and ineffective design, which is why it fits so well with the rest of browser security design :)

Reply on news.ycombinator.com