Lightboard Lessons: Perfect Forward Secrecy
Perfect Forward Secrecy allows your encrypted communications to stay secure even if a bad guy were to steal the private key of the websever you were communicating with. But, how is that possible? And, how can a web server be configured to achieve this level of security? In this video, we talk about the concept of Perfect Forward Secrecy, describe how it all works, and then show how you can configure your BIG-IP to make sure you take advantage of this really cool security functionality.Enjoy! Related Resources: Perfect Forward Secrecy Ciphers Enabling Perfect Forward Secrecy Breaking Down the TLS Handshake How RSA Works SSL Ciphers Supported on BIG-IP Platform
Stronger Keys and Faster Security with ECC
#infosec #linerate Really fast crypto in software on commodity hardware is possible after all. Anyone who has been involved with security knows there is a balance to providing both security and privacy and performance at the same time. Security is often blamed for performance woes, particularly when cryptography is involved. SSL and TLS have long addressed this balance by leveraging custom-built hardware to enhance the performance of the most taxing components of these protocols: session setup. The "easy" part of securing communications (if one can use easy with respect to cryptography) is bulk encryption. While certainly more taxing on performance than clear text, relative to the more complex and compute intensive process of the handshaking required to set up such sessions, easy is an appropriate term. Moore's Law is often cited as providing the increases in computer power necessary to offset the performance tax imposed by secure protocols. Unfortunately while this would be true if all other factors remained constant, the reality is that other factors are also changing and impose additional burdens on the protocol that often negate the gains made by Moore's Law. Key lengths, for example, continue to grow to combat the increase in compute power that makes it easier to brute-force crack a cryptographic key and new challenges with respect to privacy are changing the frequency with which those keys are generated.. There are also occasionally leaps in the mathematic realm that find ways to more quickly compute the “hard problem” that the cryptographic algorithm uses, but those are rare and don’t march at the steady pace that compute power increases do. PFS (Perfect Forward Secrecy), for example, has been offered as a way to combat potential snooping by third-parties (read: governments) by requiring the generation of ephemeral (short lived) keys for each new session. This has the effect of imposing an extra cryptography tax" on communications over and above the already expensive handshaking process required by secure protocols like SSL. Accompanying the introduction of PFS has been a move to take advantage of ECC (Elliptical Curve Cryptography). One of the primary benefits of ECC is that it can provide comparable security with shorter key lengths to RSA with longer key lengths. When you're generating ephemeral keys on a per-session or per-message basis, the shorter key length helps reduce the burden imposed by the additional cryptographic functions. Now, the problem is that cryptography is still compute intense and even leveraging ECC for PFS you're still going to incur performance penalties in setting up the session. Certainly custom cryptographic hardware acceleration would be a boon, but in cases where software-only solutions are desired, this is problematic. So the question is, how do you support enhanced security with PFS and ECC while still achieving blazing fast performance and extreme capacity? Obviously I'm about to tell you, so read on... Next-Generation Cryptography LineRate achieves what sounds like the impossible: really fast, really scalable secure communications in a software solution deployed on commodity hardware. By combining a highly optimized network stack with the ability to reach down into some of the lesser known capabilities in commoditized hardware, LineRate is able to achieve up to 25,000 new SSL sessions per second on the same commodity Intel CPU on which only 6,000-8,000 new SSL sessions per second were achieved using RSA-based cryptography. This remarkable feat is achievable through both focused engineering of the network stack and the use of a set of specialized instructions in the processor that are advantageous for the type of operations involved in ECC. These are not the same instructions as used in AES-NI, which is applicable to the easy part of SSL (bulk encryption) and aren't actually cryptography-specific instructions; they're just instructions that turn out to be really useful in speeding up the execution of certain computations associated with ECC. What this means is organizations can now take advantage of stronger security and longer (ostensibly also stronger) keys without incurring significant lags in establishing sessions. That's critical, as the longer it takes to establish a session, the more likely it is that the end-user will abandon the entire interaction. The appearance of not loading or that the site (or app) has "hung up" due to the time incurred by establishing a secure session can be devastating to the customer quality of experience. Quality of experience is rapidly outpacing other key performance indicators as a measure of success as businesses move toward an application-based economy in which engagement is key to driving revenue and customer satisfaction. A 2012 survey conducted by LSI Corporation highlighted not only the critical nature of performance (90% of respondents acknowledge this), but the disturbing reality that a majority of them (75%) do not feel they are achieving required performance. As we strengthen security to combat rising application and network attacks against protocols and applications themselves while simultaneously adopting emerging technologies and architectures designed to enable the next generation of data center networks, we must pay attention to the impact on application performance and capacity. Software-based solutions can provide the agility and service velocity demanded and necessary to enabling the app economy, but without careful consideration for the impact on performance a move toward such architectures can result in much more costly, complex networks. LineRate's attention to both performance and security offer organizations a flexible, software-defined and software-deployable solution that scales with simplicity.
Implementing ECC+PFS on LineRate (Part 1/3): Choosing ECC Curves and Preparing SSL Certificates
(Editors note: the LineRate product has been discontinued for several years. 09/2023) --- Overview In case you missed it,Why ECC and PFS Matter: SSL offloading with LineRatedetails some of the reasons why ECC-based SSL has advantages over RSA cryptography for both performance and security. This article will generate all the necessary ECC certificates with the secp384r1 curve so that they may be used to configure an LineRate System for SSL Offload. Getting Started with LineRate In order to appreciate the advantages of SSL/TLS Offload available via LineRate as discussed in this article, let's take a closer look at how to configure SSL/TLS Offloading on a LineRate system. This example will implement Elliptical Curve Cryptography and Perfect Forward Secrecy. SSL Offloading will be added to an existing LineRate System that has one public-facing Virtual IP (10.10.11.11) that proxies web requests to a Real Server on an internal network (10.10.10.1). The following diagram demonstrates this configuration: Figure 1: A high-level implementation of SSL Offload Overall, these steps will be completed in order to enable SSL Offloading on the LineRate System: Generate a private key specifying the secp384r1 elliptic curve Obtain a certificate from a CA Configure an SSL profile and attach it to the Virtual IP Note that this implementation will enable only ECDHE cipher suites. ECDH cipher suites are available, but these do not implement the PFS feature. Further, in production deployments, considerations to implement additional types of SSL cryptography might be needed in order to allow backward compatibility for older clients. Generating a private key for Elliptical Curve Cryptography When considering the ECC curve to use for your environment, you may choose one from the currently available curves list in the LineRate documentation. It is important to be cognizant of the curve support for the browsers or applications your application targets using. Generally, the NIST P-256, P-384, and P-521 curves have the widest support. This example will use the secp384r1 (NIST P-384) curve, which provides an RSA equivalent key of 7680-bits. Supported curves with OpenSSL can be found by running the openssl ecparam -list_curves command, which may be important depending on which curve is chosen for your SSL/TLS deployment. Using OpenSSL, a private key is generated for use with ssloffload.lineratesystems.com. The ECC SECP curve over a 384-bit prime field (secp384r1) is specified: openssl ecparam -genkey -name secp384r1 -out ssloffload.lineratesystems.com.key.pem This command results in the following private key: -----BEGIN EC PARAMETERS----- BgUrgQQAIg== -----END EC PARAMETERS----- -----BEGIN EC PRIVATE KEY----- MIGkAgEBBDD1Kx9hghSGCTujAaqlnU2hs/spEOhfpKY9EO3mYTtDmKqkuJLKtv1P 1/QINzAU7JigBwYFK4EEACKhZANiAASLp1bvf/VJBJn4kgUFundwvBv03Q7c3tlX kh6Jfdo3lpP2Mf/K09bpt+4RlDKQynajq6qAJ1tJ6Wz79EepLB2U40fC/3OBDFQx 5gSjRp8Y6aq8c+H8gs0RKAL+I0c8xDo= -----END EC PRIVATE KEY----- Generating a Certificate Request (CSR) to provide the Certificate Authority (CA) After the primary key is obtained, a certificate request (CSR) can be created. Using OpenSSL again, the following command is issued filling out all relevant information in the successive prompts: openssl req -new -key ssloffload.lineratesystems.com.key.pem -out ssloffload.lineratesystems.com.csr.pem This results in the following CSR: -----BEGIN CERTIFICATE REQUEST----- MIIB3jCCAWQCAQAwga8xCzAJBgNVBAYTAlVTMREwDwYDVQQIEwhDb2xvcmFkbzET MBEGA1UEBxMKTG91aXN2aWxsZTEUMBIGA1UEChMLRjUgTmV0d29ya3MxGTAXBgNV BAsTEExpbmVSYXRlIFN5c3RlbXMxJzAlBgNVBAMTHnNzbG9mZmxvYWQubGluZXJh dGVzeXN0ZW1zLmNvbTEeMBwGCSqGSIb3DQEJARYPYS5yYWdvbmVAZjUuY29tMHYw EAYHKoZIzj0CAQYFK4EEACIDYgAEi6dW73/1SQSZ+JIFBbp3cLwb9N0O3N7ZV5Ie iX3aN5aT9jH/ytPW6bfuEZQykMp2o6uqgCdbSels+/RHqSwdlONHwv9zgQxUMeYE o0afGOmqvHPh/ILNESgC/iNHPMQ6oDUwFwYJKoZIhvcNAQkHMQoTCGNpc2NvMTIz MBoGCSqGSIb3DQEJAjENEwtGNSBOZXR3b3JrczAJBgcqhkjOPQQBA2kAMGYCMQCn h1NHGzigooYsohQBzf5P5KO3Z0/H24Z7w8nFZ/iGTEHa0+tmtGK/gNGFaSH1ULcC MQCcFea3plRPm45l2hjsB/CusdNo0DJUPMubLRZ5mgeThS/N6Eb0AHJSjBJlE1fI a4s= -----END CERTIFICATE REQUEST----- Obtaining a Certificate from a Certificate Authority (CA) Rather than using a self-signed certificate, a test certificate is obtained from Entrust. Upon completing the certificate request and receiving it from Entrust, a simple conversion needs to be done to PEM format. This can be done with the following OpenSSL command: openssl x509 -inform der -in ssloffload.lineratesystems.com.cer -out ssloffload.lineratesystems.com.cer.pem This results in the following certificate: -----BEGIN CERTIFICATE----- MIIC5jCCAm2gAwIBAgIETUKHWzAKBggqhkjOPQQDAzBtMQswCQYDVQQGEwJVUzEW MBQGA1UEChMNRW50cnVzdCwgSW5jLjEfMB0GA1UECxMWRm9yIFRlc3QgUHVycG9z ZXMgT25seTElMCMGA1UEAxMcRW50cnVzdCBFQ0MgRGVtb25zdHJhdGlvbiBDQTAe Fw0xNDA4MTExODQ3MTZaFw0xNDEwMTAxOTE3MTZaMGkxHzAdBgNVBAsTFkZvciBU ZXN0IFB1cnBvc2VzIE9ubHkxHTAbBgNVBAsTFFBlcnNvbmEgTm90IFZlcmlmaWVk MScwJQYDVQQDEx5zc2xvZmZsb2FkLmxpbmVyYXRlc3lzdGVtcy5jb20wdjAQBgcq hkjOPQIBBgUrgQQAIgNiAASLp1bvf/VJBJn4kgUFundwvBv03Q7c3tlXkh6Jfdo3 lpP2Mf/K09bpt+4RlDKQynajq6qAJ1tJ6Wz79EepLB2U40fC/3OBDFQx5gSjRp8Y 6aq8c+H8gs0RKAL+I0c8xDqjgeEwgd4wDgYDVR0PAQH/BAQDAgeAMB0GA1UdJQQW MBQGCCsGAQUFBwMBBggrBgEFBQcDAjA3BgNVHR8EMDAuMCygKqAohiZodHRwOi8v Y3JsLmVudHJ1c3QuY29tL0NSTC9lY2NkZW1vLmNybDApBgNVHREEIjAggh5zc2xv ZmZsb2FkLmxpbmVyYXRlc3lzdGVtcy5jb20wHwYDVR0jBBgwFoAUJAVL4WSCGvgJ zPt4eSH6cOaTMuowHQYDVR0OBBYEFESqK6HoSFIYkItcfekqqozX+z++MAkGA1Ud EwQCMAAwCgYIKoZIzj0EAwMDZwAwZAIwXWvK2++3500EVaPbwvJ39zp2IIQ98f66 /7fgroRGZ2WoKLBzKHRljVd1Gyrl2E3BAjBG9yPQqTNuhPKk8mBSUYEi/CS7Z5xt dXY/e7ivGEwi65z6iFCWuliHI55iLnXq7OU= -----END CERTIFICATE----- Note that the certificate generation process is very familiar with Elliptical Curve Cryptography versus traditional cryptographic algorithms like RSA. Only a few differences are found in the generation of the primary key where an ECC curve is specified. Continue the Configuration Now that the certificates needed to configure Elliptical Curve Cryptography have been created, it is now time to configure SSL Offloading on LineRate. Part 2: Configuring SSL Offload on LineRate continues the demonstration of SSL Offloading by importing the certificate information generated in this article and getting the system up and running. In case you missed it,Why ECC and PFS Matter: SSL offloading with LineRatedetails some of the reasons why ECC-based SSL has advantages over RSA cryptography for both performance and security. (Editors note: the LineRate product has been discontinued for several years. 09/2023) Stay Tuned! Next week a demonstration on how to verify a correct implementation of SSL with ECC+PFS on LineRate will make a debut on DevCentral. The article will detail how to check for ECC SSL on the wire via WireShark and in the browser. In the meantime, take some time to download LineRate and test out its SSL Offloading capabilities. In case you missed any content, or would like to reference it again, here are the articles related to implementing SSL Offload with ECC and PFS on LineRate: Why ECC and PFS Matter: SSL offloading with LineRate Implementing ECC+PFS on LineRate (Part 1/3): Choosing ECC Curves and Preparing SSL Certificates Implementing ECC+PFS on LineRate (Part 2/3): Configuring SSL Offload on LineRate Implementing ECC+PFS on LineRate (Part 3/3): Confirming the Operation of SSL OffloadingLightboard Lessons: Unexpected Side Effects of Perfect Forward Secrecy
Perfect Forward Secrecy (PFS) is a great security feature that protects client and server data from being decrypted in the future. Many web servers today prefer PFS ciphers, but there are a few things to keep in mind when turning on PFS ciphers on web servers. In this video, we discuss a few of the things to keep in mind as you move toward PFS ciphers. Enjoy! Related Resources: Perfect Forward Secrecy SSL Ciphers Supported on BIG-IP PlatformLightboard Lessons: SSL Visibility - The Ultimate Inline Inspection Architecture
Now that the majority of web traffic is encrypted with Forward Secret ciphers, how do you monitor your incoming web traffic for threats? Join guest host David Holmes again this week for another Lightboard Lesson on the ultimate SSL visibility architecture for inline inspection.
