CDN mavens CloudFlare have a new system for implementing SSL in the cloud while keeping the private keys elsewhere.
CloudFlare has announced a new way for companies to use SSL in a cloud
infrastructure without having to place private keys in the cloud itself.
Called Keyless SSL, the system allows an organization to move its
public-facing Web infrastructure to the cloud, while at the same time
keeping its private SSL keys on its own internal servers.
In a phone interview, CloudFlare CEO Matthew Prince explained that
Keyless SSL is meant to remove one of the major objections many big
enterprises -- banking institutions in particular -- have about moving
to the cloud. "There are certain secrets they can't reveal, and among
them is the private SSL keys. If a bank loses a private key, that's an
event they have to report to the Federal Reserve," he said.
With a conventional SSL system, the private key used to sign all sessions is normally held on the same public-facing server used to fulfill Web traffic. The potential dangers of this system were dramatized by the Heartbleed bug, where private key information could be leaked out
Keyless SSL, however, keeps the private keys in the data center of the customer's choosing. Whenever the key is needed in the cloud, the actual key-signing request is transmitted via a private tunnel to the customer's servers where the signing itself takes place. Customers need to install an agent on their servers that satisfy those requests, but the servers in question can be behind a firewall or otherwise protected as needed. The key itself, Prince stressed, is never seen by CloudFlare or anyone else.
"The system can be load-balanced across multiple agents, geo-distributed, implemented with high availability, and so on," said Prince.
Since a round trip between the cloud and the customer's server is required for each key-signing, Prince noted that the main problem with Keyless SSL wasn't devising the technology, but making it work well at scale. Six back-and-forth steps need to be made to initiate an SSL session; Prince claims only one of those round trips needs to be between the customer's keyserver and CloudFlare's systems. Once a session is signed, it's good for a certain window of time -- the default is 24 hours -- so another round trip isn't needed for the customer during that time.
Most of the development for Keyless SSL emerged as a result of talking to bigger CloudFlare customers in the wake of a series of 2012 attacks by Iranian hackers. Many financial institutions had their on-premises defenses fail during those attacks and wanted to take advantage of CloudFlare's services, but Prince said they were reluctant to do so.
"We saw this opportunity," Prince said. "If you could make it so that you don't have to give us your private key, then we could deliver all that functionality that these big organizations had previously had to rely on on-prem equipment to solve, and we could deliver it as an infinitely scalable, infinitely elastic cloud device."
CloudFlare isn't planning to keep the technology under wraps as proprietary offering, but also open sourcing the system so that it can be implemented freely by others. The agent that sits on the client's servers, for instance, exists in a reference version written in C, but the spec can be freely reimplemented if a customer chooses to do so.
With a conventional SSL system, the private key used to sign all sessions is normally held on the same public-facing server used to fulfill Web traffic. The potential dangers of this system were dramatized by the Heartbleed bug, where private key information could be leaked out
Keyless SSL, however, keeps the private keys in the data center of the customer's choosing. Whenever the key is needed in the cloud, the actual key-signing request is transmitted via a private tunnel to the customer's servers where the signing itself takes place. Customers need to install an agent on their servers that satisfy those requests, but the servers in question can be behind a firewall or otherwise protected as needed. The key itself, Prince stressed, is never seen by CloudFlare or anyone else.
"The system can be load-balanced across multiple agents, geo-distributed, implemented with high availability, and so on," said Prince.
Since a round trip between the cloud and the customer's server is required for each key-signing, Prince noted that the main problem with Keyless SSL wasn't devising the technology, but making it work well at scale. Six back-and-forth steps need to be made to initiate an SSL session; Prince claims only one of those round trips needs to be between the customer's keyserver and CloudFlare's systems. Once a session is signed, it's good for a certain window of time -- the default is 24 hours -- so another round trip isn't needed for the customer during that time.
Most of the development for Keyless SSL emerged as a result of talking to bigger CloudFlare customers in the wake of a series of 2012 attacks by Iranian hackers. Many financial institutions had their on-premises defenses fail during those attacks and wanted to take advantage of CloudFlare's services, but Prince said they were reluctant to do so.
"We saw this opportunity," Prince said. "If you could make it so that you don't have to give us your private key, then we could deliver all that functionality that these big organizations had previously had to rely on on-prem equipment to solve, and we could deliver it as an infinitely scalable, infinitely elastic cloud device."
CloudFlare isn't planning to keep the technology under wraps as proprietary offering, but also open sourcing the system so that it can be implemented freely by others. The agent that sits on the client's servers, for instance, exists in a reference version written in C, but the spec can be freely reimplemented if a customer chooses to do so.
Hello, my name is Mohd Azahar. I'm a self-employed Pivrate from the India.
No comments:
Post a Comment