Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Universal SSL

blog.cloudflare.com

Post reply on HN
Print view View original

141–150 of 250 posts

Re: Universal SSL

#141

Post by ultramancool »

sbierwagen wrote: post #137
ultramancool wrote: post #120

Earlier quoted context omitted.

"Full SSL" is still useless against an advanced attacker as it does absolutely nothing to prevent MITM. Only "Strict SSL" does, which makes sure it's a valid CA-signed certificate. What we need (and what myself and others have requested) is Full SSL with fingerprint checking so you can keep security with a self-signed cert. I honestly think CF should remove flexible SSL and full SSL as options - they're just too vuln…

Or public key pinning: http://tools.ietf.org/html/draft-ietf-websec-key-pinning-19

Yeah, if they supported that and showed you the fingerprint of the pinned key it may be workable. My worry with that is that few of the smaller websites would bother to validate it. Pasting a fingerprint in removes the need.

Re: Universal SSL

#142

Post by nknighthb »

feld wrote: post #97
LordIllidan wrote: post #15

Earlier quoted context omitted.

Given that ssl certificates are free nowadays (e.g. https://www.startssl.com/ ), how was this not an issue before?

startssl is convenient but they force you to pay to revoke your certificates. I've heard rumors of startssl being close to getting on blacklists due to this behavior -- tons of certs were never revoked after heartbleed, for example.

Why would a phisher want to revoke their certificate?

Re: Universal SSL

#144

Post by jgrahamc »

jgrahamc wrote: post #99
edent wrote: post #98

Earlier quoted context omitted.

Faster man! Faster! :-) Thanks for doing this - such an excellent initiative.

Since you ask so nicely I had your domain bumped up in the queue.

And now...

    $ curl -v https://dabr.eu
    * Adding handle: conn: 0x7faa1c000000
    * Adding handle: send: 0
    * Adding handle: recv: 0
    * Curl_addHandleToPipeline: length: 1
    * - Conn 0 (0x7faa1c000000) send_pipe: 1, recv_pipe: 0
    * About to connect() to dabr.eu port 443 (#0)
    *   Trying 104.28.21.97...
    * Connected to dabr.eu (104.28.21.97) port 443 (#0)
    * TLS 1.2 connection using TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
    * Server certificate: sni10021.cloudflaressl.com
    * Server certificate: COMODO ECC Domain Validation Secure Server CA 2
    * Server certificate: COMODO ECC Certification Authority
    * Server certificate: AddTrust External CA Root
    > GET / HTTP/1.1
    > User-Agent: curl/7.30.0
    > Host: dabr.eu
    > Accept: */*

Re: Universal SSL

#145

Post by vtlynch »

vader1 wrote: post #75
buro9 wrote: post #39

Earlier quoted context omitted.

> this completely destroys the premise of HTTPS that you have an encrypted connection to the website you are visiting It does nothing of the kind, it has always been the case that seeing the SSL padlock only informed you that the connection to whichever server you are communicating with is encrypted and nothing more. Do you not recall the age of customer feedback pages hosted behind SSL that actually just sent plain…

Of course using HTTPS is no guarantee that the site doesn't leak your data in any other way. But never before has it been this easy to create a false sense of security: give the impression that connections to your site are encrypted, while in reality it's plaintext for half of the route. I think this will ultimately dilute the value of HTTPS as we know it, and can only hope that it will lead to the adoption of better…

I agree that this false sense of security is troubling. Many inexperienced site owners will think setting up Flexible SSL with Cloudflare is all they need to do. And it is unclear if the enduser has any way to see if the site they are connecting to is using Flexible or Full SSL.

However, in the announcement Cloudflare did say:

" Later today we'll be publishing a blog with instructions on how to do that at no cost. Once you've installed a certificate on your web server, you can enable the Full or Strict SSL modes which encrypt origin traffic and provide a higher level of security."

So this gives me a lot of hope that end to end encryption will proliferate.

What I dont understand is how they will be doing this at no cost. It looks like the certificates being issued automatically are to "xxxxxx.cloudflare.com", and not to the origin domain. Perhaps to get Full SSL you will have to enroll via Cloudflare's website to get a separate SSL that is for your site. This could then be verified the traditional way for Domain Validation certs.

Globalsign and Comodo seem to be the two providers for this.

Re: Universal SSL

#146

Post by vtlynch »

jgrahamc wrote: post #99
edent wrote: post #98

Earlier quoted context omitted.

Faster man! Faster! :-) Thanks for doing this - such an excellent initiative.

Since you ask so nicely I had your domain bumped up in the queue.

Hi John,

I know Cloudflare will be announcing later today, but how will people be enabling Full SSL (Strict) with this new rollout?

I see these certs being issued out automatically are to subdomains at cloudflare. Will customers who want to enable Full SSL (Strict) be given the ability to enroll for another certificate for free that is issued to their Common Name via your site?

(Context from Cloudflare's announcement: " Later today we'll be publishing a blog with instructions on how to do that at no cost. Once you've installed a certificate on your web server, you can enable the Full or Strict SSL modes which encrypt origin traffic and provide a higher level of security.")

Re: Universal SSL

#147

Post by shenki0 »

jgrahamc wrote: post #95
edent wrote: post #94

Interestingly, I just tried to visit one of my CloudFlare protected sites. Shoving https in front of the URL results in this error in Firefox & Chrome. dabr.eu uses an invalid security certificate. The certificate is only valid for the following names: ssl2000.cloudflare.com, .redpitt.mobi, redpitt.mobi, cloudflare.com, .cloudflare.com So I assume it isn't quite as seamless / automated as it makes out? edit ah - a li…

Your cert hasn't been issued yet. We are in the processing of issuing 2 million certs. You got a default cert that's sort of a 'catch all'. When that goes away your domain will have been issued a real cert.

Thanks for letting us know, just spent the past hour debugging this.

Perhaps get it in the FAQ so that when new users such as myself see the Error 525, we know to be patient?

Re: Universal SSL

#148

Post by jerf »

vader1 wrote: post #23

I have very mixed feelings about this. Yes, on the one hand this is great news because a lot of websites who otherwise never would have bothered with SSL can now be protected from snooping or traffic manipulation on your local (possibly very insecure: your neighborhood Starbucks' wifi) network. On the other hand, this completely destroys the premise of HTTPS that you have an encrypted connection to the website you ar…

"On the other hand, this completely destroys the premise of HTTPS that you have an encrypted connection to the website you are visiting."

Yes, you do. You are visiting a website that CloudFlare is serving, and you have encryption to that.

Other replies have already gone into how HTTPS never guaranteed anything about what happened after that, but I think that's the wrong POV. What HTTPS guarantees is that one of the central certificate authorities have authenticated that the entity they have granted the cert to is indeed that entity, and the entity can then do whatever they please with that certificate. (Which may be wrong, in which case you have already lost.)

If the entity chooses to grant CloudFlare the authority to speak in their name, then it is a statement on their part that they trust CloudFlare to do so. It is not particularly different than any other bit of internal traffic. It is and always has been the responsibility of the certificate-owning entity to decide what to do with their certificate.

This isn't new. This isn't even remotely new. The concept of allowing designated others to speak in someone's name is ancient, and even in the SSL world it has been going on forever. How many HTTPS sites are being served by Amazon or Rackspace or Linode, which are all technically capable of intercepting the plaintext request at will, or forging the response, or just plain stealing the certificate? It's bizarre to me to see people flipping out as if CloudFlare is doing something new, when it isn't new in the slightest. HTTPS has never been an assertion that the certificate holder is the only participant in the transaction. It has always been a statement of trust by the cert holder that everyone involved in the transaction is trustworthy, and it has always been the case that that statement could be in error, and it has always been the case that if that is so, you've already lost anyhow.

Re: Universal SSL

#149

Post by rang »

Good job cloudflare for finally keeping up with the industry. Cloudfront, for example, already supports universal ssl and SNI

Re: Universal SSL

#150

Post by driverdan »

peterwwillis wrote: post #121
logn wrote: post #33

Earlier quoted context omitted.

What they should do is require that the server has at least a self-signed certificate. They already support that but don't require it.

What good would that do? A self-signed cert is about as secure as no cert at all. (Unless they implement their own form of certificate pinning for the origin, which would cause problems for sites with multiple certs on the same host, which is quite common)

So long as CF pins the cert it's perfectly safe.
Post reply on HN