psilva's prophecies: pki

Showing posts with label pki. Show all posts

Tuesday, November 3, 2015

Ask the Expert – Why SSL Everywhere?

Kevin Stewart, Security Solution Architect, talks about the paradigm shift in the way we think about IT network services, particularly SSL and encryption. Gone are the days where clear text roams freely on the internal network and organizations are looking to bring SSL all the way to the application, which brings complexity. Kevin explains some of the challenges of encrypting all the way to the application and ways to solve this increasing trend. SSL is not just about protecting data in motion, it’s also about privacy.

Technorati Tags: f5,ssl,encryption,pki,big-ip,security,privacy,silva,video

Connect with Peter:	Connect with F5:

Tuesday, October 19, 2010

The New Certificate 2048 My Performance

SSL is a cryptographic protocol used to secure communications over the internet. SSL ensures secure end-to-end transmission and is implemented in every Web browser. It can also be used to secure email, instant messaging and VoIP sessions. The encryption and decryption of SSL is computationally intensive and can put a strain on server resources like CPU. Currently, most server SSL Certificates are 1024-bit key length and the National Institute of Standards and Technology (NIST) is recommending a transition to 2048-bit key lengths by Jan 1^st 2011.

SSL and its brethren, TLS (Transport Layer Security) provide the security and encryption necessary for secure communications over the internet, and particularly for creating an encrypted link between the browser and web server. You will see ‘https’ in your browser address bar when visiting a site that is SSL enabled. The strength of SSL is tied to the size of the Public Key Infrastructure (PKI) key. Key length or key size (1024 bit, 2048 bit, 4092 bit) is measured in bits and typically used to indicate the strength of the encryption algorithm; the longer the key length, the harder it is decode. In order to enable an SSL connection, the server needs to have a digital certificate installed. If you have multiple servers, each requiring SSL, then each server must have a digital certificate.

Transactions handled over SSL can require substantial computational power to establish the connection (handshake) and then to encrypt and decrypt the transferred data. If you need the same performance as non-secured data, then additional computing power (CPU) is needed. SSL processing can be up to 5 times more computationally expensive than clear text to have the same level of performance, no matter which vendor is providing the hardware. This can have significant, detrimental ramifications to server performance. SSL Offload takes much of that computing burden off the servers and places it on dedicated SSL hardware. SSL offload allows organizations to migrate 100% of their communications to SSL for greater security, consolidation of certificates, centralized management, and reduction of cost and allows for selective content encryption & encrypted cookies along with the ability to inspect and modify encrypted traffic. SSL offloading can relieve the Web server of the processing burden of encrypting and/or decrypting traffic sent via SSL.

Customers, vendors and the industry as a whole will soon face the challenge of what to do regarding their SSL strategy. Those who have valid 1024-bit certificates need to understand the ramifications of the switch and that next time they go to renew their certificates, they will be forced to buy 2048-bit certificates. This will drastically affect their SSL capacity on both the servers and the load balancer. There is a significant increase in needed computational power going from 1024-bit to 2048-bit and an exponential drop off in performance when doubling key sizes regardless of the platform or vendor. Most CAs, like Entrust have already stopped issuing 1024-bit certificates, and Verisign will stop doing so in 4-5 months. Since many certificate vendors are now only issuing 2048-bit certificates, customers might not understand the potential SSL performance capacity. The overall performance impact of 2048-bit keys on the servers if you don’t offload will increase significantly. This can be a challenge when you have hundreds of servers providing content

Existing certificates issued with 1024-bit encryption will not stop working. If you still have valid certificates but need to ensure you are delivering 2048-bit certificates to users (or due to regulatory requirements), one option, as mentioned in Lori’s blog, is to install the 2048-bit certificate on your BIG-IP LTM for the off-load performance capabilities and then use your existing 1024-bit keys from BIG-IP LTM to the back-end server farm. Simply import the server certificates directly into BIG-IP. This means that the SSL Certificates that would normally go on each server can be centrally stored and managed by LTM, thereby reducing the cost of the certificates needed as well as the cost for any specialized server software/hardware required. This keeps the load off the servers, potentially eliminating any performance issues and allows you to stay current with NIST guidelines while still providing an end to end SSL connection for your web applications. This is a huge advantage over commodity hardware with no SSL offload capabilities. BIG-IP LTM has specialized SSL chips which are dedicated and optimized for SSL encryption and decryption. These chips provide the ability to maintain performance levels even at longer key lengths, whereas in commodity hardware the computational load of SSL decreases the overall system performance impacting user experience and other server tasks.

The F5 SSL Acceleration Module removes all the bottlenecks for secure, wire-speed processing, including concurrent users, bulk throughput, and new transactions per second along with supporting certificates up to 4092-bits. The fully loaded F5 VIPRION chassis is the most powerful SSL-offloading engine on the market today and, along with the BIG-IP LTM Virtual Edition (VE), provides a powerful solution to the SSL challenge. By front-ending BIG-IP VE farms with a VIPRION, you can assign load balancing or SSL offloading to a dedicated ADC. The same approach can remedy access to legacy systems that might not support 2048-bit certificates or cannot be upgraded due to business restrictions or other rationale. By deploying an F5 BIG-IP device with 2048k certificate in front of the legacy systems, back-end encryption can be accomplished using existing 1024-bit certificates. F5 does support 4096-bit keys, future-proofing support for longer keys down the road and offers backwards and forwards compatibility but unless there is a strong business case, 2048-bit keys are recommended for optimal performance and protection.

ps

Related:

Technorati Tags: F5, infrastructure 2.0, integration, cloud computing, Pete Silva, security, business, education, technology, application delivery, cloud, context-aware, infrastructure 2.0, web, internet

twitter: @psilvas

Friday, June 25, 2010

Audio Tech Brief - Constrained Delegation in CAC PKI Architectures

Kerberos has long been considered to reside at the top of the network authentication protocol tree as the most secure and, unfortunately, most complex authentication system. This comes not from the way in which Kerberos is designed, but rather from the complexity of the systems that have grown up around Kerberos that support identity management, especially when applied across organizational boundaries. Using the F5 BIG-IP Local Traffic Manager to support federation of cross-domain service access in a PKI-enabled architecture. Running time: 16:20 Read full white paper here.

Download now or listen on posterous

Audio_Tech_Brief_-_Constrained_Delegation_in_CAC_PKI_Architectures.mp3 (15328 KB)

And click here for more F5 Audio.

twitter: @psilvas

Technorati Tags: F5, infrastructure 2.0, integration, cloud connect, Pete Silva, security, business, education, technology, application delivery, intercloud, cloud, context-aware, infrastructure 2.0, automation, web, internet

Posted via email from psilva's prophecies

Tuesday, December 22, 2009

Post-Blog Report: 26 Short Topics about Security

Aloha and welcome to the post-blog report. Over the last 5 months, I’ve been writing a blog series called, 26 Short Topics about Security and wanted to share some observations. First, I went about this since there are so many IT challenges when it comes to security and it’s virtually impossible to cover them all. Plus, I’m always looking for interesting stats and stories pertaining to security and thought I’d gather them up in one place. It’s sort of a 2009 ‘Security Greatest Hits’ (or Misses, if you’re a Devo fan).

If you are a blogger and sometimes have difficulty producing a consistent stream of valuable conversations, a blog series will do the trick. You’re not alone since Perseus reports that 66.0% of surveyed blogs had not been updated in two months, "representing 2.72 million blogs that have been either permanently or temporarily abandoned.” I had a daily urge to continue my quest and keep the flow going rather than jumping on ‘whatever the topic/crisis of the day’ was and writing about that. Interestingly, the timing of many of the topics coincided with a recent event, so it worked out well. Specific keywords in the titles, like Firewall, Virtualization, Twitter or any other term that’s hot (frequently searched) drew the most readers even if the title was a little ‘out there.’ And like any writer, I was a little surprised by the entries that got the most attention. You know the routine, you think something is fantastic but nobody cares and the ones you feel are a little weak get massive reads. Go figure.

The other thing I tried during this series is to both include a ton of links (Don MacVittie called it a link-fest) to referring stories along with links to the previous stories in the series for easy perusal. When one got read, so did multiple others which positively influenced Pages per Visit and Average Time on Site – key metrics for any website. Finally, I’m thinking about recording the blogs to offer an audio version (à la Audio Whitepapers) of the series.

Now to put a bow on this – All 26 Short Topics about Security:

Bonus blog: Bit.ly, Twitter, Security & You

Wednesday, September 16, 2009

Keys to the Kingdom

According to various history sites, the earliest known lock to be key operated was from Egypt, some 4000 years ago. It was wooden and actually used moveable pegs that fell into holes to secure the ‘bolt.’ The wooden key would move the pins back into place to allow the lock to be opened. And, of course, Caesar is credited with inventing the first cipher. Ahh, love history and always fun to know where some of today’s technologies came from.
In security, specifically cryptography, a key is a specific number value that when used with an algorithm can encrypt and decrypt a block of data – usually text. The key length or size, typically in bits or bytes, determines how strong the encryption is and thus how difficult it might be to decrypt.
There is Symmetric and Asymmetric encryption. With symmetric encryption, only one ‘secret key’ is used on both ends to encrypt and decrypt messages. This is one of the oldest encryption techniques and can be as simple as shifting or replacing a letter. This works great if both parties have the secret shared key but it needs to stay SECRET. The bad side is that it’s just a single key and if someone gets a hold of it, then they can possibly intercept and decrypt your hidden messages. Key management, such as changing the secret key often and distributing it securely to authorized users can be a challenge.
In Asymmetric encryption, also called Public Key – Private Key cryptography, two keys are used – one for encryption and one for decryption. The private key is always kept secret while the public key is out in the wild often in the form of a certificate. So you can have my public key, in fact I might just give it to you, since that will be what you use to either encrypt a message to me or decrypt a message from me. It is my private key that will do all the mashing so i can read your encrypted note and respond in secret. The unique keys are paired and by using the same algorithm we can communicate incognito and no other key (or pair) can decrypt the data. This infrastructure can also be useful to prove identity and ensure the message has not been tampered.
Then why PKI? When you send an encrypted message, it is digitally signed with your private key but I’m not standing next to you watching the ink hit the paper. PKI is what validates trust. With certificates (your public key) there is usually a Certificate Authority who is essentially a third-party vouch. Yes you can create self-signed certs but with a Cert Authority, they can verify your identity (or signature) and add their own signature as a stamp of approval. PKI can store your certificates, revoke certificates, backup/recover keys, time stamp and a bunch of other services. While public keys are meant to be public, their integrity is essential and PKI can accomplish that.
Like anything security related, nothing is foolproof. Secure distribution of keys is essential to prevent Man in the Middle attacks. You might ask for my public key and I sent it to you, but someone else intercepts it on the way. They send a forged note to you along with their public key, claiming to be me. You decrypt the message since you think it’s from me and subsequently send an encrypted note back, but you’ve encrypted it with the interceptor’s key. They grab it again, in transit, decrypt, keep a copy, re-encrypt with my original public key and forward on. When I get it, I still believe it came from you and no one’s the wiser. Simple additions like passwords for private keys or mutual authentication can help defend against MITM among other techniques (pdf).
I realize this was not my usual ‘link-fest’ entry with stats and fun stories, there are a slew of mathematical computations to make this all work and many other components to effective key management and deployment. But for number 11 of 26 Short Topics, I just wanted to convey that your digital Keys are an integral part of keeping your data secure from eavesdropping and tampering and can verify that you are transmitting it to/from from a trusted entity. Too bad the trusty TRIX Decoder rings are no longer available.
ps

#11 out of 26 Short Topics about Security
previous stories: 10, 9, 8, 7, 6, 5, 4, 3, 2, 1

psilva's prophecies