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

Keyless SSL: The Nitty Gritty Technical Details

blog.cloudflare.com

Post reply on HN
Print view View original

21–30 of 69 posts

Re: Keyless SSL: The Nitty Gritty Technical Details

#21

Post by justinsb »

alexwilliamsca wrote: post #13

The Keyless SSL server is open source and available on GitHub - https://github.com/cloudflare/keyless - although I'm wondering if its dependence on OpenSSL was a good choice.

My guess is that the customer for whom they developed this has crypto-acceleration hardware that is supported by OpenSSL. Also, this is only doing the actual crypto operations, not running the whole SSL protocol.

Edit: I guess it's also exposing SSL publicly for talking to CloudFlare, which is I guess why they suggested IP firewalling as well (in case of another HeartBleed).

And it's only a reference implementation!

Re: Keyless SSL: The Nitty Gritty Technical Details

#22

Post by buro9 »

vader1 wrote: post #15
jgrahamc wrote: post #11

Earlier quoted context omitted.

In some ways what you propose sounds even scarier, i.e. figure out the best way to look inside SSL encrypted data without having the key. But in terms of privacy and trust, CloudFlare is already in the position of terminating SSL connections and establishing new ones to origin web servers. We take the protection of that data and the associated keys very seriously. There will be more announcements over the coming week…

I'm not quite following how having just enough insights about the encrypted data to perform DDOS mitigation would be scarier than having full read- and write access to the cleartext. Thanks for the responses though, and definitely looking forward to those blogs.

You are implying something fundamental: that the encrypted traffic could be adequately analysed for insight without the need for decryption.

Yet to do so would be to defeat SSL itself, or at least to declare it as insufficient to adequately protect secrets.

What CloudFlare is doing isn't defeating SSL or any kind of attack on it. They are merely working around some prior limitations on requiring access to an organisation's private key.

As a proxy that is charged with DDoS protection (and other types of protection and performance improvements), they are being asked to terminate and work on the unencrypted data to a very strict set of complience by the end organisations, but they need to do this in a way that does not involve possessing or having access to the private key.

Their solution works extremely well given the multiple constraints (technological and legal) that they have.

Re: Keyless SSL: The Nitty Gritty Technical Details

#23

Post by mr_brown »

jackgavigan wrote: post #10
vader1 wrote: post #4

Interesting how they specifically refer to yesterday's discussion here on HN and over at Reddit, but don't go into the frequently mentioned complaint that despite not having access to the PK itself, Cloudflare can still intercept and modify all cleartext sent between the client and server, which for most intents and purposes means pretty much the same. Maybe not intentionally so, but it comes off as slightly misleadi…

The problem that Keyless SSL is solving is the need for a client to hand over their SSL keys to Cloudflare in order to use Cloudflare's services. It eliminates the risk that the key will be stolen from Cloudflare and used by the Bad Guys to set up a fake website to steal everyone's credentials. You might not perceive how big the benefit of this is but you're not the target market. I used to handle the SSL encryption…

CDNs are used to deliver static, highly cacheable content, like assets, images, media content, stuff that will be delivered to many users. It is very rare that a website serves this type of content under the same domain as the dynamic content (think cdn1.whatnot.com, assets-myapp.com). In fact for applications with a lot of assets this is a must because of domain sharding and to avoid the overhead of sending the cookies on every single request. Since you need a different domain, you can (you don't have to) use a different certificate, so it's not a strech to use a different private key.

Then there are the applications where security is more important than latency - online banking, payment gateways, tax filing. Those applications don't have too much cache-able content so they simply won't benefit from CDNs.

I also don't see how is this faster. Sure, CloudFlare Keyless SSL is faster than serving the content yourself, but sending that packet over the internet is always going to be slower than not. So now I have a slower (compared to the CDN having my key), more complicated option that requires me to run an additional keyserver and doesn't provide me additional security. The only upside of this seems to be good PR.

Depending how sensitive the content is, in fact if I could I would choose to deliver it over plain HTTP and sign it somehow. That would be best of both worlds.

Edit: I admit I totally missed the point about DDoS protection.

Re: Keyless SSL: The Nitty Gritty Technical Details

#24

Post by nknighthb »

mr_brown wrote: post #23
jackgavigan wrote: post #10

Earlier quoted context omitted.

The problem that Keyless SSL is solving is the need for a client to hand over their SSL keys to Cloudflare in order to use Cloudflare's services. It eliminates the risk that the key will be stolen from Cloudflare and used by the Bad Guys to set up a fake website to steal everyone's credentials. You might not perceive how big the benefit of this is but you're not the target market. I used to handle the SSL encryption…

CDNs are used to deliver static, highly cacheable content, like assets, images, media content, stuff that will be delivered to many users. It is very rare that a website serves this type of content under the same domain as the dynamic content (think cdn1.whatnot.com, assets-myapp.com). In fact for applications with a lot of assets this is a must because of domain sharding and to avoid the overhead of sending the cook…

I think you may be missing that one of CloudFlare's key features is DDoS protection (and in fact it was a DDoS that initially caused the banks to approach them), including at the application layer. That functionality cannot be fulfilled without CloudFlare having access to the content of the communications, nor can any of their other application-layer security functions.

Re: Keyless SSL: The Nitty Gritty Technical Details

#25

Post by jackgavigan »

mr_brown wrote: post #23
jackgavigan wrote: post #10

Earlier quoted context omitted.

The problem that Keyless SSL is solving is the need for a client to hand over their SSL keys to Cloudflare in order to use Cloudflare's services. It eliminates the risk that the key will be stolen from Cloudflare and used by the Bad Guys to set up a fake website to steal everyone's credentials. You might not perceive how big the benefit of this is but you're not the target market. I used to handle the SSL encryption…

CDNs are used to deliver static, highly cacheable content, like assets, images, media content, stuff that will be delivered to many users. It is very rare that a website serves this type of content under the same domain as the dynamic content (think cdn1.whatnot.com, assets-myapp.com). In fact for applications with a lot of assets this is a must because of domain sharding and to avoid the overhead of sending the cook…

Cloudflare isn't just a CDN. They protect against DDoS attacks. That is what financial instututions are interested in.

You should read eastdakota's blog post from yesterday: https://news.ycombinator.com/item?id=8334933

Re: Keyless SSL: The Nitty Gritty Technical Details

#26

Post by rakoo »

higherpurpose wrote: post #6

It's one thing to keep SHA1 in old services, but why do they keep pushing SHA1 into new ones ?

From the user POV, nothing is changed. The decision to deprecate SHA1 or not isn't specific to Keyless SSL (ie, Keyless SSL isn't a new product for the users)

From the bank's point of view, where we can say that Keyless SSL is a new product, only 2 cipher suites are allowed:

    ECDHE-ECDSA-AES256-GCM-SHA384
    ECDHE-RSA-AES256-GCM-SHA384
which, as you can see, don't include sha1.

Re: Keyless SSL: The Nitty Gritty Technical Details

#29

Post by peterwaller »

mrfusion wrote: post #28

So from a non-technical business owner perspective this means I can offer SSL for free without buying certs or making changes to my server?

No. This allows a content delivery network (such as cloudflare) to host content on your behalf without having to have direct access to your private key material.

The main use cases you may be interested in are to 1) make it so that users connecting to you get a faster experience - since they can connect to a geographically nearby cloudflare server, rather than your distant server and 2) make it so that cloudflare can absorb large denial-of-service attacks that your server couldn't otherwise cope with.

Re: Keyless SSL: The Nitty Gritty Technical Details

#30

Post by mrfusion »

peterwaller wrote: post #29
mrfusion wrote: post #28

So from a non-technical business owner perspective this means I can offer SSL for free without buying certs or making changes to my server?

No. This allows a content delivery network (such as cloudflare) to host content on your behalf without having to have direct access to your private key material. The main use cases you may be interested in are to 1) make it so that users connecting to you get a faster experience - since they can connect to a geographically nearby cloudflare server, rather than your distant server and 2) make it so that cloudflare can…

Ok thanks. So this basically makes it easier and more secure to get set up with cloudflare?

So why couldn't Cloudflare set up what I'm suggesting? Are there technical reasons, or just lack of demand?

Post reply on HN