Live data from Hacker News

Universal SSL

blog.cloudflare.com

221–230 of 250 posts

Re: Universal SSL

#221

Once IPv6 is a bit more popular, will CloudFlare use a unique IP per customer to get around SNI or will it still be used on IPv6? It seems a bit like NAT; something that can safely die once IPv4 is gone.

So, you want NAT to die, but apparently you forget that NAT is what protects most domestic computers from intrusion, not anti-virus or software firewalls. It will be fun...

NAT is not security.

Re: Universal SSL

#222

Earlier quoted context omitted.

Actually, that's a good model. It would have kept the memory (and code execution domain) of the application server independent from the memory of the SSL terminator during Heartbleed. If you terminate SSL on the same box as your app server you're putting many eggs into one basket.

Except that didn't really make much of a difference in the case of heartbleed. The information was still in memory decrypted, before it was encrypted by the front end, so an attacker could get the decrypted content, which may include users usernames/passwords and all that fun stuff.

Yes, you could get the data going to and from the clients, which is most of the important user data. The big problem is when your SSL/http/whatever is being terminated on the app server itself, exposing things like database access, SANs, etc.

Re: Universal SSL

#223
post #195

Can somebody explain to me 1) why SSL certificats are so expensive 2) Why do they have to expire?

1) theoretically, it's essentially the background check the CA's perform to ensure you are you 2) to ensure you still are you, and to setup a nice recurring revenue stream for the CA's :) (err it probably has something to do with security)

Re: Universal SSL

#224

Earlier quoted context omitted.

> How often have you encountered read-only network access? Public wireless points (i.e. Firesheep), any network with a hub instead of a switch...

None of those are read-only.

I don't recall ever being on a public hotspot that let me change its DNS settings to hijack other users' Facebook traffic.

Re: Universal SSL

#225
post #195

Can somebody explain to me 1) why SSL certificats are so expensive 2) Why do they have to expire?

1) They are not, really. You can get free DV certs from StartSSL. Other types of certs do cost money because issuing them involves real work. I don't know how else to explain it. Go look at the list of things a CA has to do to be considered trustable by the major root store operators (operating system vendors, browser makers). It's not trivial.

2) The original reason was because it was assumed (correctly) that due to hardware improvements keys that were previously strong would become weak. So it was supposed to encode a length of time after which the cert owner would be forced to re-evaluate key strength. Nowadays the browser makers are tending to lean on CAs to push expiry times downwards so they expire quicker, the reason being that updating the SSL ecosystem often requires new features or changes in certificates, and if certs can last 5 years then it means a full upgrade takes 5 years, whereas if certs expire after one year then one year after deployment begins everyone is updated. Pretty big difference. It's for this reason that EV certs are specced to expire after a year: it means standards can be revved quicker.

Re: Universal SSL

#226

My website that is behind Cloudflare on the free plan, has suddenly started giving me an error in Google Chrome. The error is as follows: You cannot visit mysite.com right now because the website uses HSTS. Network errors and attacks are usually temporary, so this page will probably work later. The website has been running for over a year with no problems behind Cloudflare, so I'm assuming this new rollout is the cau…

Did you ever get a resolution to this?

Re: Universal SSL

#227

Earlier quoted context omitted.

Consent yes, though I can't fully parse "procedures established by". What procedures are meant here? https://cabforum.org/wp-content/uploads/Baseline_Requirement... "The CA MUST ensure that the certificate is issued with the consent of, and according to procedures established by, the owner of each Domain Name" EDIT: Here are the established authorization procedures: "11.1.1 Authorization by Domain Name Registrant For…

> Having the Applicant demonstrate practical control over the FQDN by making an agreed-upon change to information found on an online Web page identified by a uniform resource identifier containing the FQDN CloudFlare arguably has the consent of the domain holder (gray area but probably in CF's favor) and can pass the required validation. I do partially agree that the domain holder (CloudFlare's customer) should have…

For Cloudflare to work, they require that you use their DNS servers on the domain so that provides good validation.

Re: Universal SSL

#228

Earlier quoted context omitted.

None of those are read-only.

I don't recall ever being on a public hotspot that let me change its DNS settings to hijack other users' Facebook traffic.

DNS spoofing is the most trivial attack there is on a public hotspot. The 'dnsspoof' tool was packaged with DSniff over 13 years ago. Even if you don't directly spoof DNS, there's a bunch of ways to intercept or change DNS traffic on a public hotspot, like ARP, IP or access point hijacking. Any 'how to hack' book will cover it.

Re: Universal SSL

#229
post #210
post #196

Earlier quoted context omitted.

pushed forward by browser makers Huh? Which browser alerts me when the cert changes from the previous one that it has seen for a site? That would be the most basic and trivial mitigation for a start. What we see instead is consortium paralysis for decades . Occam's razor much? HSTS does nothing for certificate trust. And the other two you mentioned still conveniently keep us at the mercy of browser vendors and infras…

Sites need to be able to update their certs without giving a scary warning to all their repeat visitors.

Sites need to be able to update their certs without giving a scary warning to all their repeat visitors.

Why?

Why shouldn't sites be forced to announce these changes beforehand?

Why can't we have a "defer all trust to $certificate_authority"-button for the lazy users?

Why is "blind trust" still the default after all these years?

Why can't I even selectively enable a warning when the certificate changes for sites that I really care about (like my bank)?

Re: Universal SSL

#230

Earlier quoted context omitted.

Except that didn't really make much of a difference in the case of heartbleed. The information was still in memory decrypted, before it was encrypted by the front end, so an attacker could get the decrypted content, which may include users usernames/passwords and all that fun stuff.

Yes, you could get the data going to and from the clients, which is most of the important user data. The big problem is when your SSL/http/whatever is being terminated on the app server itself, exposing things like database access, SANs, etc.

No, it wouldn't expose those things. It would only expose things that OpenSSL itself had allocated/deallocated in that single process due to the way it was saving memory allocations for later re-use...
Post reply on HN