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 Offloading
SSL off-loading and secure WebSocket
Hi, We have a Big-IP load balancer, and we are planning to publish a web application that uses secure WebSockets (WSS). We are a little bit concerned about how the load balancer is going to handle this situation, because the SSL offloading. Is there anything special we have to configure or taken care off? Clients will send an HTTPS request with a WebSocket handshake, that includes the HTTP headers "Upgrade:websocket" and "Connection:Upgrade". Will the load balancer populate those headers to the web server? Will the load balancer understand that those connections are persistent and non-HTTP? Thanks.
SSL Orchestrator config error
Hello, Do you know how to revert or correct a configuration error on sslo? The only way we managed to get rid of an error is to completely delete the sslo config and recreate it again. There is a message saying that we have to click on undeploy and try again but I don't see any undeploy button!! We're running sslo version 5 Thanks
SSL Offloading for BlueCoat explicit proxy
Hello. A client's BlueCoat proxy is falling short on resources. It performs SSL interception so it can inspect the whole packet. Given this, they've asked if and how to configure the F5 so it offloads the SSL, thus having the client part of the proxied connection in plain text (from the proxy's POV). The scenario looks something like this: Client --- -->[F5]------>[BC]----->[F5]------>Internet (The BlueCoat speaking HTTPS with servers is not resource intensive). I have struggled with the SSL intercept iApp, and SSL orchestrator. With SSLO, navigation works, however it seems to not be offloading SSL. Anything is helpful. Thanks!
SSL offload and HTTPs persistence
Hi, Currently i have HTTP clients accessing two Servers in a pool behind an F5. I need persistence towards the two Servers and im using a Persistence Profile with HTTP iRule . Now the customer wants to use HTTPS Clients towards the two Servers which will have HTTPS ports configured. As i want to keep persistence towards the two Servers i understand from reading other posts here that i need to offload SSL in F5 so decrypt, run HTTP Persistence iRule and then encrypt again. Am i correct in that thinking? Im wondering about the way to implement this on F5. Both Servers will have the same SSL cert/key. To make this work do i create a VS with type "standard" and then create a Client and Server SSL Profile using the SSL cert/key from the Servers? As regards the iRule, do i need to modify the rule below replacing HTTP with HTTPS or leave it as is?Crypto Client's clientssl profile config issue(External Crypto )
Hi Everyone Who has configured external crypto function ? Crypto Client's clientssl profile cert&key and Crypto Server's crypto-server-default-clientssl profile cert&key is the same? This guide “https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/bigip-ssl-administration-12-0-0/18.html” is not very clear about the certificate requirements. Many thanks D.LuoAbout F5 VE External Cryptographic issue.
Hi Everyone I refer to this guide https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/bigip-ssl-administration-12-0-0/18.html in my lab. Client -----> BIGIP-1 VE v12.1 (Crypto client) -----> BIGIP-2 VE v12.1( Crypto Server ) I used tmsh commany show crypto server have normal output at below. Sys::Crypto Server: my_Crypto_Server Received Packets 156 Received Bytes 6.1K Transmitted Packets 156 Transmitted Bytes 3.8K But client web browser display common name is localhost.localdomain by Crypto client's default clientssl cert，It not by Crypto server's crypto-server-default-clientssl cert. My understanding was that use External Crypto function and its purpose is to use the Crypto server security save and management certificate. The Crypto server is responsible for the final SSL offload function.So I think client browser dispaly certificate should be Crypto server's instead of Crypto client 's localhost.localdomain. Do I understand correctly and How to correctly configured? Many Thanks D.Luo
Certificate Issue : unable to find valid certification path to requested target
Hello, We deployed a staging e-payment application, using a Virtual Server with these properties : port : https protocol profile : mptcp-mobile-optimized HTTP Profile : XFF SSL Profile : 2 certificates - The issued certificate & a second certificate with Default SSL Profile for SNI SNAT Pool : ip in the same subnet as nodes. Pool : 2 pool members with port 7010 I'm using public certificates (signed by CA Verisign G5 & CA Symantec G4) the web page is displayed correctly, & SSL checks says all is ok (tested with "; & ";) the actual issue is that transaction doesn't pass over https (in http it works fine) here's the error message relived from client side : -An exception occured in HTTPProcess sendMessage. Exception: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target. - doPost exception encountered. Exception: java.lang.NullPointerException. can you support us please?Full proxy not working when try to use SSL offload + HTTP-to-HTTPS redirect
Hi Everyone I've some question about Full proxy with SSL offload. My scenario is I've web application which run on port 80. And then I try to make it to HTTPS for all path by using F5 LTM policie which redirect all HTTP request to HTTPS and perform SSL offload. Problem is application doesn't working properly after do that. I'm not sure why it's not working. From concept of Full proxy, This should working with no problem because F5 have isolate client-side and server-side (server-side still send traffic on port 80) . At first I think it due to HTML hardcode on application but it's not correct due to F5 still send traffic on port 80 the same as before. Is there any concern when using HTTP-to-HTTPS redirect + SSL offload ? Thank you
