SSL Profiles Part 6: SSL Renegotiation
This is the sixth article in a series of Tech Tips that highlight SSL Profiles on the BIG-IP LTM. SSL Overview and Handshake SSL Certificates Certificate Chain Implementation Cipher Suites SSL Options SSL Renegotiation Server Name Indication Client Authentication Server Authentication All the "Little" Options This article will discuss SSL renegotiation, some OpenSSL features, some of the attack vectors against SSL renegotiation, and then how the BIG-IP is configured to handle this feature. What Is SSL Renegotiation? Before we get into the details of SSL renegotiation, let me start by outlining a quick scenario. Let's say a user visits an online shopping site that is SSL encrypted. Initially, the user shops around anonymously, but after some time on the site, the user decides to log in and make a purchase. The user will need to authenticate to the site before making the purchase, so the SSL connection will need to be adjusted to allow the authentication. Ideally, all the information the user collected as an anonymous visitor will be maintained and protected after the status change to an authenticated customer. This basic (yet frequent) scenario outlines the need for SSL renegotiation. The figure below shows a representation of this scenario and shows that a new SSL session must be established in order to authenticate the user. This new session completes the full handshake, but it does it using the security of the already-established SSL connection. SSL renegotiation messages (including types of ciphers and encryption keys) are encrypted and then sent over the existing SSL connection. This feature is nice because it can create a secure SSL session based on the fact that a secure connection is already established. SSL renegotiation is useful in several situations where an ordinary SSL session is already established. Here are a few examples: Client authentication is required A different set of encryption and decryption keys are needed A different set of encryption and hashing algorithms are used The client or the server can request renegotiation at any time. For the client to request renegotiation, the client sends a "Client Hello" message in the already-established encrypted channel and the server responds with a "Server Hello" and then the negotiation follows the normal handshake process. The server can initiate the renegotiation by sending the client a Hello Request message. When the client receives the request, the client sends the "Client Hello" message and the handshake process takes place. One quick note of clarification: the client and server can also complete a session resumption vice a session renegotiation. A session resumption basically resumes a previous session (using a previous session ID), and it saves the client and server the computing work of generating new encryption keys. Renegotiation is a process by which the full handshake process takes place over an already existing SSL connection. A Fly In The Ointment... Life would be much easier if the bad guys weren't out there doing their thing, but I guess it would also be less interesting. Nonetheless, some pretty smart guys were working with SSL renegotiation back in the old days (circa 2009) and found out that they could exploit a vulnerability in its design. The Common Vulnerabilities and Exposures (CVE) database outlines the details behind this SSL renegotiation vulnerability in CVE-2009-3555. You can read the details for yourself, but here's what the CVE basically says: TLS and SSLv3 do not properly associate renegotiation handshakes with an existing connection, and this allows attackers to insert data into existing sessions by sending an unauthenticated request that is processed retroactively by a server in a post-renegotiation context related to a "plaintext injection" attack. Essentially, this means that bad guys can hijack the SSL session and start using your "secure" communications on your behalf. Houston, we have a problem. Fortunately, the good folks at the Internet Engineering Task Force (IETF) found out about this problem, and they responded with a little magic of their own. It's outlined in Request for Comments (RFC) 5746. Here's what they had to say: "Secure Socket Layer (SSL) and Transport Layer Security (TLS) renegotiation are vulnerable to an attack in which the attacker forms a TLS connection with the target server, injects content of his choice, and then splices in a new TLS connection from a client. The server treats the client's initial TLS handshake as a renegotiation and thus believes that the initial data transmitted by the attacker is from the same entity as the subsequent client data. This specification defines a TLS extension to cryptographically tie renegotiations to the TLS connections they are being performed over, thus preventing this attack." Well, take that bad guys!! A Few Notes About OpenSSL Now that we have a basic understanding of RFC 5746, let's spend some time on OpenSSL and how it relates to F5's BIG-IP. After all, how can you have an article on SSL and not talk about OpenSSL? This stuff is free (Apache style) and it's awesome! The BIG-IP supports the popular OpenSSL toolkit, and it even has a built-in OpenSSL utility. It's important to understand how OpenSSL handles the behavior of clients and servers regarding the feature of SSL renegotiation. OpenSSL 0.9.8m and later always attempts to use secure renegotiation as described in RFC 5746. On the BIG-IP side of the house, versions prior to 10.2.3 do not support this RFC. However, beginning in version 10.2.3 and 11.x, the BIG-IP SSL profiles do support it. So, pause for a few minutes from reading this article and upgrade your BIG-IP! Patching When describing SSL implementations, systems that support secure renegotiation (per RFC 5746) are referred to as "patched" and systems that do not support secure renegotiation are referred to as "unpatched." If a client and server are both patched, connections and renegotiation are always permitted by OpenSSL implementations. If a server is patched but the client is unpatched, the initial connection will succeed but client renegotiation will be denied by the server with a no_renegotiation warning alert if TLS v1.0 is used or a fatal handshake_failure alert if SSL v3.0 is used. If the patched server attempts to renegotiate with the unpatched client, a fatal handshake_failure alert is sent. This is because the server code may be unaware of the unpatched nature of the client. Here's what happens if a client is patched but the server is unpatched. If the option "SSL_OP_LEGACY_SERVER_CONNECT" or "SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION" is set then initial connections as well as all renegotiations between patched clients and unpatched servers will succeed. However, if neither option is set then initial connections to unpatched servers will fail. (note: the option "SSL_OP_LEGACY_SERVER_CONNECT" is currently set by default, but as more servers become patched, this option will not be set by default in future versions of OpenSSL). Renegotiation Attacks Speaking of highly broken...let's spend a little time on SSL renegotiation attacks before we dive into the BIG-IP configurations. Here are two fairly well known attacks that are targeted at the SSL renegotiation feature. And, guess what? I'm starting with the..."Man in the Middle" (sung to Michael Jackson's hit song) Man In The Middle Since we discussed RFC 5746 earlier, why not go over the details of what it fixed? As we've discussed, SSL allows both servers and clients to initiate a complete renegotiation of the encryption parameters used for SSL connections. However, the design of the initial handshake and the renegotiation process had a gap that could allow an attacker to send a “Client Hello” and insert content into a client’s SSL session and then intercept secure communications between the server and the client. The following illustration shows how a bad guy could exploit the Man in the Middle vulnerability. In this example, the client sends a "Client Hello" to start an SSL session with his bank's server. The bad guy temporarily blocks the "Client Hello" and then creates an SSL connection of his own with the server. After the SSL session is created between the bad guy and the bank server, the bad guy asks for a money transfer. The bank server needs to authenticate the user, so it requests a renegotiation by sending a "Hello Request" to the bad guy...which is exactly what he wanted. This is where the bad guy sends the client's initial "Client Hello" to the server. The client thinks he is beginning a new SSL session, and the server thinks an SSL renegotiation has just taken place. But, nonetheless, all parties are happy with everything...especially the bad guy! See, now you know why you should be using a "patched" system! Denial of Service Last year, the IETF posted a paper that outlines a Denial of Service (DoS) attack against a server using the SSL renegotiation feature. The DoS attack is based on the fact that an SSL handshake requires up to 10 times more processing power on the server than on the client. Therein lies the problem...and the ability to exploit it! When SSL renegotiation is enabled on the server, a user is allowed to send a renegotiation request any time he wants...and this request initiates a new handshake. Since it takes much fewer resources for a client to perform a handshake than a server, the client can request multiple handshakes per second and cause a DoS on the server side SSL interface. Therefore, if a malicious user requests multiple renegotiation requests it will exhaust the server’s resources and not allow any other user to establish a connection. This attack is different than a Distributed Denial of Service (DDoS) as it does not require a large amounts of network volume to exhaust the network connection. Instead, it exhausts the server resources from a single host requiring only a single TCP/IP socket. A single server can perform between 150-300 handshakes per second while a single client can request up to 1,000 handshakes per second. By the way, Openssl doesn't consider this DoS exploit an actual vulnerability (which is why they haven't done anything about it in their latest releases). Their response is that this exploit is a way of DoS'ing a server by requesting lots of expensive crypto operations. Any app that allows an operation like SSL renegotiation to an untrusted host is subject to resource exhaustion. They would say the correct answer is to restrict hosts if this is an issue. Note also that if the OS firewall is not enabled, any OS is subject to a DoS through resource exhaustion, even if it's just TCP port exhaustion. For more information on a great SSL renegotiation DoS countermeasure, see this DevCentral article. David Holmes and Jason Rahm teamed up to talk about the DoS vulnerability, and then they wrote an iRule that elegantly defeats the attack...really cool and useful stuff!! In addition, here's a quick video clip that talks about the same issue...F5 knocks it out of the park with this iRule stuff! F5 Security Vignette: SSL Renegotiation BIG-IP Configuration Now that we've talked through this SSL renegotiation thing, let's finish up with the features of the BIG-IP and how it handles SSL renegotiation. The following screenshot shows the different options for SSL renegotiation on the BIG-IP. You can find this screen by navigating to Local Traffic > Profiles > SSL > Client | Server. Notice that you can either enable or disable SSL renegotiation altogether. By default, it is enabled. Renegotiation controls (on a per-connection basis) how the BIG-IP responds to mid-stream SSL reconnection requests. When enabled, the system processes mid-stream SSL renegotiation requests. When disabled, the system terminates the connection, or ignores the request, depending on system configuration. The Renegotiate Period setting specifies the number of seconds from the initial connect time that the system renegotiates an SSL session. The options are "Specify" (in seconds) and "Indefinite" with "Indefinite" being the default. The "Indefinite" setting means that you never want the system to force an SSL renegotiation. The system will renegotiate the session after the specified period of time...that's why the "Indefinite" setting never forces a renegotiation. For example, setting the renegotiate period to 3600 seconds triggers session renegotiation at least once an hour. The Renegotiate Size setting forces the BIG-IP to renegotiate an SSL session after a specified number of megabytes of application data have been transmitted over the secure channel. The values for this setting are "Indefinite" and "Specify" (in megabytes) with "Indefinite" being the default. This setting follows the same premise as the Renegotiate Period but it uses data size to determine when it will force a renegotiation vice a period of time. The Renegotiate Max Record Delay setting forces the BIG-IP to terminate an SSL session after receiving the specified maximum number of SSL records. The number of records are counted while the BIG-IP system waits for the client to initiate a renegotiation. If the BIG-IP system receives more than the maximum number of SSL records, it closes the connection. The values for this setting are "Indefinite" and "Specify" (number of records). The default setting is "Specify" 10 records. Secure Renegotiation is a fairly new feature in the BIG-IP (not available prior to v10.2.3). This setting handles the RFC 5746 problem, and it allows the user to specify the method of secure renegotiation for SSL connections. The values for this setting are "Request," "Require," and "Require Strict" with "Require" being the default value for the Client-side SSL profile. The default value for the Server-side SSL profile depends on the BIG-IP version: in v10.2.3 and v10.2.4, the default value for the Server-side SSL profile is "Require" and the default value in v11.x is "Require Strict." The "Request" value specifies that the system simply requests secure renegotiation of SSL connections. The "Require" value specifies that the system requires secure renegotiation of SSL connections. In this mode, the system permits initial SSL handshakes from clients, but terminates renegotiations from unpatched clients. The "Require Strict" value specifies that the system requires strict secure renegotiation of SSL connections. In this mode, the system does not accept new SSL connections from unpatched clients. Within the context of the Server-side SSL profile, there is no behavioral difference between "Require" and "Require Strict." In either mode, initial SSL connections from the BIG-IP to unpatched servers will fail. Conclusion Well, I think that about does it for SSL Renegotiation. Come back for more great SSL discussion in our next article that will feature Server Name Indication (SNI). As always, if you have any questions (about SSL, iRules, or any other F5 technology), feel free to comment here or contact the DevCentral team directly. See you soon!SSL Profiles Part 2: Certificates
This is part 2 in a series of tech tips on the F5 BIG-IP LTM SSL profiles. SSL Overview and Handshake SSL Certificates Certificate Chain Implementation Cipher Suites SSL Options SSL Renegotiation Server Name Indication Client Authentication Server Authentication All the "Little" Options In part 1, we covered the basics of the TLS handshakes and the context of the client and server ssl profiles. This time we’ll take a look at certficates. What is an SSL Certificate? The certificate is nothing more than a document containing the public key the client will use to compute key material and information about expiration, common and distinguished names, contact information, etc. A certificate can be modified until it is signed. This can be done to itself, which would be a self-signed certificate (all root certificates are self-signed) or a certificate can be signed by a certificate authority (CA). The certificate below in Figure 1 might look familiar. I created this certificate from a private certificate authority I set up when looking at HTTP Strict Transport Security a couple months back. That begs another question: What is a certificate authority? SSL Certificate Authorities The CA is one component within the larger public key infrastructure (PKI). CA’s serve as a trusted 3rd party between server and client, issuing (and revoking) the certificates. The server and optionally the client (owners) request a certificate that is signed by the CA. Both client and server then host the CA’s root and/or intermediate certificates. As shown above, you can be your own CA, but this increases the management burden as you now need to distribute the root/intermediate certificates to your clients in order to gain their trust of your certificates. By using a commercial CA, chances are good their certificates are already in your client trusted stores and thus your certificates will be trusted by the clients. In a corporate network, however, you might want to secure your traffic without forking over the cash for dozens (hundreds?) of certificates. In this case, an internal CA makes a lot of sense, and can be managed somewhat painlessly with active directory or the like. Figure 2 shows the testco CA as installed in my firefox browser. So any certificates I sign with the testco CA will be trusted by my firefox browser, eliminating all the extra clicking I’d need to do for self-signed certificates. Intermediate CAs and the Certificate Chain Best practices with PKI involve creating a number of subordinate CAs. With the testco CA I created, I installed this root certificate into my trust store and I signed the certificate I used for www.testco.com with that CA, and all is well. However, most of the time certificates are signed by Leaf CAs, or subordinate CAs that are created specifically for the purpose of creating certificates for servers, systems, etc. If you reference Figure 1, you’ll notice the issuer section where it informs the client of the certificate signer. In the event this is not the root CA for my www.testco.com, the authentication will fail, because the issuer is not trusted. These trust relationships can chain so that there are multiple levels of trust down from the root certificate to a depth of 10 (openSSL). For example, take the certificate chain in Figure 3. When the client receives the certificate from www.testco.com, it will have a signer (issuer) of Testco Dev CA. My browser doesn’t trust this CA, so it must then validate its signer, which is the Testco CA (root). My browser does trust this CA, so all is good. Now, if I added this intermediate CA to my trust store, validation would stop at that level and would not need to climb to the root CA. This is how most commercial providers work. You get the intermediate CAs from most publishers when you install your system OS. When you connect to an SSL-enabled site, the certificate arrives at the client with it’s signer, and then the certificate chain is climbed until (if) it arrives at a level of trust. In addition to the usefulness for the ssl profiles, this information is quite handy if you will be installing 3rd party certificates (read: not self-signed) for GTM (Chapter 12 in the Implementations Guide) as certificate depth plays a big role in configuration. Finally, IBM has a great graphic on the chain of trust certificate/signature verification process. Types of Certificates Remember from part 1 where I said that you couldn’t host multiple domains on a single IP without the TLS SNI option? Well, that’s not entirely true. It is true of standard SSL certificates, but certificates have changed over the years to workaround some of these limitations. There are several options when considering certificates. Domain Validated – no company background checking, just a simple comparison to the domain whois information before issuing. $ Organizationally Validated – company background is vetted, site ip/name is validated. $$ Extended Validation – industry standard certificate guidelines. This will turn the browser locator bar green and publish company name as well. Introduced in 2007. $$$ Unified Communications – this certificate takes advantage of the Subject Alternative Name field, so you can secure multiple (specific) domain names on one certificate. Microsoft Exchange is a popular application requiring a UC Certificate, as it supports several names owa.site.com, autodiscover.site.com, cas1.site.com, etc. $$$ Wildcard Certificate – this certificate supports any number of subdomains based on *.site.com, where your subdomain would replace the *. It doesn’t, however, support site.com, so for those lazy users (me) who hate typing the leading www. before hitting enter, the wildcard certificate will not cover that scenario. $$$ Wildcard Plus – This is a combination UCC/Wildcard Certificate in that it will protect at the site.com, *.site.com, and several specified lower-subdomain levels as well. Most modern browsers support the above options, but there are still some questions on the compatibility with the wildcard plus certificates, and some mobile devices have issues with wildcard certificates in general. Make sure you thoroughly vet out your userbase before deciding on a solution. Certificate Formats There are several ways the X.509 certificate structure is packaged. Different platforms require different formats. The LTM uses PEM format. Most of the commercial CAs issue certificates in PEM format. If you are using an internal Windows CA, most likely the certificate, the format is PKCS#7/#12, and prior to version 10.1, needed to be converted to PEM prior to import. The formats used are: PEM – base64 encoded ASCII file with BEGIN CERTIFICATE and END CERTIFICATE statements and can contain the private key DER – binary form of the certificate PKCS#7 – also a base64 encoded ASCII file, though with BEGIN PKCS7 and END PKCS7 statements. Can not contain the private key. PKCS#12 – binary form of the certificate, any intermediates, and the private key. Converting is fairly easy and can be done at the cli of the LTM with the openssl tool. DER to PEM openssl x509 -inform der -in <certname>.der -out <certname>.pem PKCS#7 to PEM openssl pkcs7 -print_certs -in <certname>.p7b -out <certname>.pem PKCS#12 to PEM openssl pkcs12 -in <certname>.pfx -out <certname>.pem -nodes Conclusion There is so much more depth to certificates that we could cover, but hopefully this overview has been informative and provides the foundation necessary for part 3, where we’ll start diving into the profiles themselves.SSL Profiles Part 10: All The "Little" Options
This is the tenth article in a series of Tech Tips that highlight SSL Profiles on the BIG-IP LTM. SSL Overview and Handshake SSL Certificates Certificate Chain Implementation Cipher Suites SSL Options SSL Renegotiation Server Name Indication Client Authentication Server Authentication All the "Little" Options The first nine articles in this series highlighted many important SSL features on the BIG-IP. In this article, I will overview some of the features that were not highlighted in the first nine articles. This article will feature the Proxy SSL option, ModSSL Methods option, Session Caching (size and timeout), Strict Resume (with a little sprinkle of Unclean Shutdown), Session Ticket, and Non-SSL Connections. Many of these are a simple checkbox on the BIG-IP GUI, but they are still important features of the SSL profile! So, sit back, grab a healthy helping of your favorite beverage (mine is Ski), and enjoy this final article in the SSL profile series. Here's a quick screenshot of the features that we will highlight in this article. As always, you can find these features by navigating to Local Traffic > Profiles > SSL > Client | Server. Proxy SSL When you set up the BIG-IP to process your application data, you might want the destination server to authenticate the client directly instead of relying on the BIG-IP to perform this function. You may have a web application firewall in place to secure the communications between requesting clients and the service. In this case, you might want to implement Proxy SSL. Proxy SSL gives the server the final authority in allowing or denying client access. Retaining direct client-server authentication provides full transparency between the client and server systems. This feature is disabled by default, but in order to enable it you must configure both the Client and Server SSL profiles and check the "ProxySSL" box on each profile. It's important to note that the certificate and key that you specify in the Server SSL profile must match the certificate/key pair that you expect the backend server to offer. If the backend server has more than one certificate/key pair, then you must create a separate Server SSL profile for each one. When all profiles (Client and Server) are created, you assign them to the virtual server that will handle the SSL traffic. Without the Proxy SSL feature enabled, the BIG-IP establishes separate client-side and server-side SSL connections and then manages the initial authentication of both the client and server systems. With the Proxy SSL feature, the BIG-IP enables direct client-server authentication by establishing a secure SSL tunnel between the client and server systems and then forwarding the SSL handshake messages from the client to the server and vice versa. After the client and server successfully authenticate each other, the BIG-IP system uses the tunnel to decrypt the application data and manipulate (optimize) the data as needed. ModSSL Methods ModSSL is an optional module for Apache HTTP servers that provides strong cryptography by using SSL and TLS protocols. This module relies on OpenSSL to provide the cryptography engine. The ModSSL package for Apache servers includes benefits like: Availability for both Unix and Windows platforms Support for RSA and Diffie-Hellman ciphers Clean reviewable ANSI C source code Clean Apache module architecture Full Dynamic Shared Object (DSO) support Advanced pass-phrase handling for private keys X.509 certificate based authentication for both client and server X.509 certificate revocation list (CRL) support Support for per-URL renegotiation of SSL handshake parameters Support for explicit seeding of the PRNG with external sources Inter-process SSL session cache (DBM or Shared Memory based) Powerful dedicated SSL engine logging facility Simple and robust application to Apache source trees If you are using Apache HTTP servers in your environment, this BIG-IP feature will be nice to have. For more on the Apache ModSSL module, check out this link. To enable ModSSL method emulation, simply check the box. Be aware that it is disabled by default. Cache Size The Cache Size setting specifies the number of SSL sessions allowed in the cache. If you want to disable SSL session caching for a profile, you simply set the Cache Size to zero. The SSL session Cache Size limits the number of sessions that are cached for a particular profile. When the cache limit is reached, the oldest SSL session associated with that profile is deleted from the cache and the new SSL session is added to the cache. SSL caching is beneficial especially when dealing with SSL session resumption. The ability to cache and reuse SSL session IDs can increase transactions per second by limiting processor-intensive key exchange functions. While the Cache Size can be configured for each SSL profile, it's important to note that the combined total Cache Size of all active SSL profiles on a BIG-IP is limited by the global session cache size, and the global session Cache Size setting is not configurable. The default and global Cache Sizes for an SSL profile differs based on BIG-IP versions: BIG-IP versions 9.x through 10.0.1 has a default SSL cache size of 20,000 sessions and a global SSL cache size of 32,768 sessions BIG-IP versions 10.1.0 through 11.x has a SSL cache size of 262,144 sessions for both global and default settings If you create several SSL profiles, be sure to limit the total Cache Size to a value less than or equal to the global Cache Size value of the BIG-IP version you are running (using the values listed above). If the combined total Cache Size of all SSL profiles is larger than the global limit, you might run into sharing problems where entries on one virtual server may be deleted from cache in favor of another virtual server even if the Cache Size for that profile has not been reached. Cache Timeout Cache Timeout is an easy one...it simply specifies the timeout value (in seconds) of the SSL session cache entries. There are two options for Cache Timeout on the dropdown menu: Specify and Indefinite. The default is set to Specify: 3600. The indefinite setting simply means the cache entries in the SSL session will never time out. If you have an issue with hitting your limit on Cache Size, you will want to avoid the Indefinite setting for Cache Timeout. On that same note, if you have Cache Size limit issues, you can decrease the value of the Cache Timeout setting until you find a happy place for your session cache. Finally, if you are running < v10.1.0, just upgrade and you'll get tons of extra cache space! Strict Resume (with a sprinkle of Unclean Shutdown) The Strict Resume feature is also pretty straightforward. However, I'll warn you...this setting can get into that weird space of double-negatives. So, unless you really want to think through this one, you should just keep the default settings on everything. If you disable Strict Resume (the default value), the BIG-IP will resume SSL sessions after an unclean shutdown. If you enable this setting, the system will not resume SSL sessions after an unclean shutdown. Essentially, the system is either going to be strict about session resumption or not (enabled / disabled respectively). So, we've mentioned the term "unclean shutdown" because it is important relative to Strict Resume, but what is it? As you can imagine, a "clean shutdown" is the way the SSL protocol was designed to handle the issue of terminating SSL connections. The SSL protocol performs a clean shutdown of an active SSL connection by sending a close notify alert to the peer system. On the other hand, the "unclean shutdown" closes the underlying connections without sending the SSL close notify alerts. The "Unclean Shutdown" is enabled on the BIG-IP by default because certain web browsers handle SSL shutdown alerts differently. For example, some versions of Internet Explorer require SSL shutdown alerts from the server while other versions do not, and the SSL profile can't always detect this requirement. So, be aware of the way the "Strict Resume" and "Unclean Shutdown" settings interact with one another. Pop quiz: If "Unclean Shutdown" is disabled, does it matter what you do with the "Strict Resume" setting? Session Ticket This setting enables or disables the use of SSL session tickets. Session tickets are outlined in RFC 5077. This setting is disabled by default. Session Tickets enable the server to resume SSL sessions and avoid keeping per-client session states. To accomplish this, the server encapsulates the session state into a ticket and forwards it to the client. The client can then subsequently resume a session using the obtained ticket. Non-SSL Connections This setting enables or disables the acceptance of non-SSL connections. The BIG-IP will still accept SSL connections if this setting is enabled, but it will also accept non-SSL connections. This setting is disabled by default. If enabled, non-SSL connections will pass through the BIG-IP in clear-text. So, obviously, proceed with caution on this one. I'm not saying there's not a reason out there to use this setting, but you should be certain of what you are doing before clicking the box on this one! Conclusion Well, that does it for this SSL article. We will continue to post new articles highlighting the SSL profile as new features are introduced. If you have any questions feel free to leave a comment here or Contact DevCentral directlySSL Profiles Part 9: Server Authentication
This is the ninth article in a series of Tech Tips that highlight SSL Profiles on the BIG-IP LTM. SSL Overview and Handshake SSL Certificates Certificate Chain Implementation Cipher Suites SSL Options SSL Renegotiation Server Name Indication Client Authentication Server Authentication All the "Little" Options This article will discuss the concept of Server Authentication, why it's important, and how the BIG-IP system allows you to configure it for your environment. Server Authentication During a TLS handshake, a client and server exchange information and ultimately create a secure (encrypted) connection. My previous article in this series (client authentication) discussed the need for the server to authenticate the client. Many customers want to know that the correct user is accessing their server, so client authentication is important for them. Well, in many cases, the same is true on the client side. If a client accesses a server, he wants to know that he is connected to the right server. While the TLS handshake establishes a secure connection between the client and server, it does not inherently prove that the client has connected to the correct server. Server authentication is a feature that allows the client to know that he is accessing the correct server. To illustrate the concept of server authentication, let's start with a simple example of a client connecting to a server using the TLS handshake. But, in this example, let's say another server steps in and attempts a "man in the middle" attack on the connection. This scenario is illustrated in the following diagram. In this scenario, the client wants to establish a secure connection with Server 1. But Server 2 intercepts the connection request and sends its certificate back to the client instead. In the meantime, Server 2 establishes it's own secure connection with Server 1. When the client receives the certificate from Server 2, it checks the certificate against its list of trusted Certificate Authorities (CA). Since the certificate from Server 2 is signed by a trusted CA, the client establishes the secure connection. For more on SSL certificates, see article 2 of this series. Now that Server 2 has a secure connection with the client and Server 1, he can intercept (and manipulate) all subsequent communications between the two. So far nothing has violated the TLS protocol, but we still have a problem, right? After all, the client is connected to the wrong server! I probably don't have to spend too much time convincing you this is less than ideal. A quick example using your personal or business bank website should be more than enough evidence to prove that we need to do something about all this. The Server Authentication feature has been introduced to help avoid these problems. As discussed earlier, server authentication provides a way for the client to know that he is connected to the correct server. In server authentication, the client establishes a secure connection with the server using the TLS handshake, but before the client sends any data it checks to make sure the Common Name [CN] of the server matches the CN of the certificate. If these names don't match, the client terminates the session immediately. The following diagram shows this process. In this example, the client initiates a TLS handshake with Server 1, but the handshake is intercepted by Server 2. As in the previous example, Server 2 acts as a "man in the middle" and is potentially able to manipulate data flowing to/from the client and Server 1. When server authentication is used, the client will inspect the CN of the certificate it receives and compare it to the CN of the server it is trying to reach. In this example, let's say the CN for Server 1 is www.server1.com and the CN for Server 2 is www.server2.com. When the client receives the server certificate as part of the TLS handshake process, the CN on the certificate will say www.server2.com. When the client compares that CN to the server he was trying to reach (www.server1.com), the CN will not match and the connection will be terminated immediately. This protects the client from establishing a connection with an unknown server. BIG-IP Configuration Now that we've established the foundation for server authentication, let's figure out how the BIG-IP is set up to handle this feature. The following screenshot shows the user interface for configuring Server Authentication. To get here, navigate to Local Traffic > Profiles > SSL > Server. The Server Certificate setting specifies the way the system handles server certificates and has two values: Ignore and Require. The Ignore value is the default and it specifies that the system ignores certificates from server systems. The Require value specifies that the system requires a server to present a valid certificate. These settings effectively turn on and off the server authentication feature of the BIG-IP. If you select Require as the Server Certificate value, you will also need to specify a value in the Authenticate Name setting as well. A blank Authenticate Name field means that every server is authenticated even though you have specified Require as the Server Certificate value. Expire Certificate Response Control specifies how to handle connections from a client whose server certificate is expired. The two values for this setting are Ignore and Drop. The Ignore value specifies that the system ignores the expired server certificate and still allows the connection. The Drop value is the default and it specifies that the system drops connections with expired server certificates. Untrusted Certificate Response Control specifies how to handle connections from a server whose certificate is untrusted (i.e. signed by an invalid CA). The two values for this setting are Ignore and Drop. The Ignore value specifies that the system ignores the untrusted server certificate and still allows the connection. The Drop value is the default and it specifies that the system drops connections from servers with untrusted certificates. Frequency specifies the frequency of server authentication for an SSL session. This setting offers two values: Once and Always. The Once value is the default and it specifies that the system will authenticate the server only once for an SSL session. The Always setting specifies that the system will authenticate the server once when the SSL session is established as well as each time the session is reused. The Retain Certificate box is checked by default. When checked, the server certificate is retained for the SSL session. Certificate Chain Traversal Depth specifies the maximum number of certificates that can be traversed in a server certificate chain to find a trusted CA. The default for this setting is 9. For more on certificate chains, see article 3 of this SSL series. Authenticate Name specifies a CN that is embedded in a server certificate. The BIG-IP authenticates a server based on the specified CN. The CN must be a valid Fully Qualified Domain Name [FQDN], so the Authenticate Name must also be a FQDN. Remember, if you select the Require value in the Server Certificate setting, you should also specify a value in the Authenticate Name setting as well. The Trusted Certificate Authorities setting is used to specify the BIG-IP's Trusted Certificate Authorities store. These are the CAs that the BIG-IP trusts when it verifies a server certificate that is presented during server authentication. The default value for the Trusted Certificate Authorities setting is None, indicating that no CAs are trusted. Note that if the Server Certificate menu is set to Require and the Untrusted Certificate Response Control is set to Drop, you must select an option other than None for the Trusted Certificate Authorities setting...otherwise, all SSL connections will be dropped. The drop down list in this setting includes the name of all the SSL certificates installed in the BIG-IP's /config/ssl/ssl.crt directory. A newly-installed BIG-IP system will include the following certificates: default certificate and ca-bundle certificate. The default certificate is a self-signed certificate used when testing SSL profiles. This certificate is not appropriate for use as a Trusted Certificate Authorities certificate bundle. The ca-bundle certificate is a bundle of CA certificates from most of the well-known PKIs around the world. This certificate may be appropriate for use as a Trusted Certificate Authorities certificate bundle. However, if this bundle is specified as the Trusted Certificate Authorities certificate store, any valid client certificate that is signed by one of the popular Root CAs included in the default ca-bundle.crt will be authenticated. This provides some level of identification, but it provides little access control since almost any valid client certificate could be authenticated. If you want to trust only certificates signed by a specific CA or set of CAs, you should create and install a bundle containing the certificates of the CAs whose certificates you trust. The bundle must also include the entire chain of CA certificates necessary to establish a chain of trust. Once you create this new certificate bundle, you can select it in the Trusted Certificate Authorities drop down menu. The Certificate Revocation List (CRL) setting allows you to specify a CRL that the BIG-IP will use to check revocation status of a certificate prior to authenticating a server. If you want to use a CRL, you must upload it to the /config/ssl/ssl.crl directory on the BIG-IP. The name of the CRL file may then be entered in the CRL setting dialog box. Note that this box will offer no drop down menu options until you upload a CRL file to the BIG-IP. Since CRLs can quickly become outdated, you should use either OCSP or CRLDP profiles for more robust and current verification functionality. Conclusion Well, that wraps up our discussion on Server Authentication. I hope the information helps, and I hope you never establish a secure connection with a malicious web server again! Be sure to come back for our last article in the SSL series. As always, if you have any questions, feel free to comment here or contact us directly atDevCentral - Contact Us.SSL Profiles Part 8: Client Authentication
This is the eighth article in a series of Tech Tips that highlight SSL Profiles on the BIG-IP LTM. SSL Overview and Handshake SSL Certificates Certificate Chain Implementation Cipher Suites SSL Options SSL Renegotiation Server Name Indication Client Authentication Server Authentication All the "Little" Options This article will discuss the concept of Client Authentication, how it works, and how the BIG-IP system allows you to configure it for your environment. Client Authentication In a TLS handshake, the client and the server exchange several messages that ultimately result in an encrypted channel for secure communication. During this handshake, the client authenticates the server's identity by verifying the server certificate (for more on the TLS handshake, see SSL Overview and Handshake - Article 1in this series). Although the client always authenticates the server's identity, the server is not required to authenticate the client's identity. However, there are some situations that call for the server to authenticate the client. Client authentication is a feature that lets you authenticate users that are accessing a server. In client authentication, a certificate is passed from the client to the server and is verified by the server. Client authentication allow you to rest assured that the person represented by the certificate is the person you expect. Many companies want to ensure that only authorized users can gain access to the services and content they provide. As more personal and access-controlled information moves online, client authentication becomes more of a reality and a necessity. How Does Client Authentication Work? Before we jump into client authentication, let's make sure we understand server authentication. During the TLS handshake, the client authenticates the identity of the server by verifying the server's certificate and using the server's public key to encrypt data that will be used to compute the shared symmetric key. The server can only generate the symmetric key used in the TLS session if it can decrypt that data with its private key. The following diagram shows an abbreviated version of the TLS handshake that highlights some of these concepts. Ultimately, the client and server need to use a symmetric key to encrypt all communication during their TLS session. In order to calculate that key, the server shares its certificate with the client (the certificate includes the server's public key), and the client sends a random string of data to the server (encrypted with the server's public key). Now that the client and server each have the random string of data, they can each calculate (independently) the symmetric key that will be used to encrypt all remaining communication for the duration of that specific TLS session. In fact, the client and server both send a "Finished' message at the end of the handshake...and that message is encrypted with the symmetric key that they have both calculated on their own. So, if all that stuff works and they can both read each other's "Finished" message, then the server has been authenticated by the client and they proceed along with smiles on their collective faces (encrypted smiles, of course). You'll notice in the diagram above that the server sent its certificate to the client, but the client never sent its certificate to the server. When client authentication is used, the server still sends its certificate to the client, but it also sends a "Certificate Request" message to the client. This lets the client know that it needs to get its certificate ready because the next message from the client to the server (during the handshake) will need to include the client certificate. The following diagram shows the added steps needed during the TLS handshake for client authentication. So, you can see that when client authentication is enabled, the public and private keys are still used to encrypt and decrypt critical information that leads to the shared symmetric key. In addition to the public and private keys being used for authentication, the client and server both send certificates and each verifies the certificate of the other. This certificate verification is also part of the authentication process for both the client and the server. The certificate verification process includes four important checks. If any of these checks do not return a valid response, the certificate verification fails (which makes the TLS handshake fail) and the session will terminate. These checks are as follows: Check digital signature Check certificate chain Check expiration date and validity period Check certificate revocation status Here's how the client and server accomplish each of the checks for client authentication: Digital Signature: The client sends a "Certificate Verify" message that contains a digitally signed copy of the previous handshake message. This message is signed using the client certificate's private key. The server can validate the message digest of the digital signature by using the client's public key (which is found in the client certificate). Once the digital signature is validated, the server knows that public key belonging to the client matches the private key used to create the signature. Certificate Chain: The server maintains a list of trusted CAs, and this list determines which certificates the server will accept. The server will use the public key from the CA certificate (which it has in its list of trusted CAs) to validate the CA's digital signature on the certificate being presented. If the message digest has changed or if the public key doesn't correspond to the CA's private key used to sign the certificate, the verification fails and the handshake terminates. Expiration Date and Validity Period: The server compares the current date to the validity period listed in the certificate. If the expiration date has not passed and the current date is within the period, everything is good. If it's not, then the verification fails and the handshake terminates. Certificate Revocation Status: The server compares the client certificate to the list of revoked certificates on the system. If the client certificate is on the list, the verification fails and the handshake terminates. As you can see, a bunch of stuff has to happen in just the right way for the Client-Authenticated TLS handshake to finalize correctly. But, all this is in place for your own protection. After all, you want to make sure that no one else can steal your identity and impersonate you on a critically important website! BIG-IP Configuration Now that we've established the foundation for client authentication in a TLS handshake, let's figure out how the BIG-IP is set up to handle this feature. The following screenshot shows the user interface for configuring Client Authentication. To get here, navigate to Local Traffic > Profiles > SSL > Client. The Client Certificate drop down menu has three settings: Ignore (default), Require, and Request. The "Ignore" setting specifies that the system will ignore any certificate presented and will not authenticate the client before establishing the SSL session. This effectively turns off client authentication. The "Require" setting enforces client authentication. When this setting is enabled, the BIG-IP will request a client certificate and attempt to verify it. An SSL session is established only if a valid client certificate from a trusted CA is presented. Finally, the "Request" setting enables optional client authentication. When this setting is enabled, the BIG-IP will request a client certificate and attempt to verify it. However, an SSL session will be established regardless of whether or not a valid client certificate from a trusted CA is presented. The Request option is often used in conjunction with iRules in order to provide selective access depending on the certificate that is presented. For example: let's say you would like to allow clients who present a certificate from a trusted CA to gain access to the application while clients who do not provide the required certificate be redirected to a page detailing the access requirements. If you are not using iRules to enforce a different outcome based on the certificate details, there is no significant benefit to using the "Request" setting versus the default "Ignore" setting. In both cases, an SSL session will be established regardless of the certificate presented. Frequency specifies the frequency of client authentication for an SSL session. This menu offers two options: Once (default) and Always. The "Once" setting specifies that the system will authenticate the client only once for an SSL session. The "Always"setting specifies that the system will authenticate the client once when the SSL session is established as well as each time that session is reused. The Retain Certificate box is checked by default. When checked, the client certificate is retained for the SSL session. Certificate Chain Traversal Depth specifies the maximum number of certificates that can be traversed in a client certificate chain. The default for this setting is 9. Remember that "Certificate Chain" part of the verification checks? This setting is where you configure the depth that you allow the server to dig for a trusted CA. For more on certificate chains, see article 2 of this SSL series. Trusted Certificate Authorities setting is used to specify the BIG-IP's Trusted Certificate Authorities store. These are the CAs that the BIG-IP trusts when it verifies a client certificate that is presented during client authentication. The default value for the Trusted Certificate Authorities setting is None, indicating that no CAs are trusted. Don't forget...if the BIG-IP Client Certificate menu is set to Require but the Trusted Certificate Authorities is set to None, clients will not be able to establish SSL sessions with the virtual server. The drop down list in this setting includes the name of all the SSL certificates installed in the BIG-IP's /config/ssl/ssl.crt directory. A newly-installed BIG-IP system will include the following certificates: default certificate and ca-bundle certificate. The default certificate is a self-signed server certificate used when testing SSL profiles. This certificate is not appropriate for use as a Trusted Certificate Authorities certificate bundle. The ca-bundle certificate is a bundle of CA certificates from most of the well-known PKIs around the world. This certificate may be appropriate for use as a Trusted Certificate Authorities certificate bundle. However, if this bundle is specified as the Trusted Certificate Authorities certificate store, any valid client certificate that is signed by one of the popular Root CAs included in the default ca-bundle.crt will be authenticated. This provides some level of identification, but it provides very little access control since almost any valid client certificate could be authenticated. If you want to trust only certificates signed by a specific CA or set of CAs, you should create and install a bundle containing the certificates of the CAs whose certificates you trust. The bundle must also include the entire chain of CA certificates necessary to establish a chain of trust. Once you create this new certificate bundle, you can select it in the Trusted Certificate Authorities drop down menu. The Advertised Certificate Authorities setting is used to specify the CAs that the BIG-IP advertises as trusted when soliciting a client certificate for client authentication. The default value for the Advertised Certificate Authorities setting is None, indicating that no CAs are advertised. When set to None, no list of trusted CAs is sent to a client with the certificate request. If the Client Certificate menu is set to Require or Request, you can configure the Advertised Certificate Authorities setting to send clients a list of CAs that the server is likely to trust. Like the Trusted Certificate Authorities list, the Advertised Certificate Authorities drop down list includes the name of all the SSL certificates installed in the BIG-IP /config/ssl/ssl.crt directory. A newly-installed BIG-IP system includes the following certificates: default certificate and ca-bundle certificate. The default certificate is a self-signed server certificate used for testing SSL profiles. This certificate is not appropriate for use as an Advertised Certificate Authorities certificate bundle. The ca-bundle certificate is a bundle of CA certificates from most of the well-known PKIs around the world. This certificate may be appropriate for use as an Advertised Certificate Authorities certificate bundle. If you want to advertise only a specific CA or set of CAs, you should create and install a bundle containing the certificates of the CA to advertise. Once you create this new certificate bundle, you can select it in the Advertised Certificate Authorities setting drop down menu. You are allowed to configure the Advertised Certificate Authorities setting to send a different list of CAs than that specified for the Trusted Certificate Authorities. This allows greater control over the configuration information shared with unknown clients. You might not want to reveal the entire list of trusted CAs to a client that does not automatically present a valid client certificate from a trusted CA. Finally, you should avoid specifying a bundle that contains a large number of certificates when you configure the Advertised Certificate Authorities setting. This will cut down on the number of certificates exchanged during a client SSL handshake. The maximum size allowed by the BIG-IP for native SSL handshake messages is 14,304 bytes. Most handshakes don't result in large message lengths, but if the SSL handshake is negotiating a native cipher and the total length of all messages in the handshake exceeds the 14,304 byte threshold, the handshake will fail. The Certificate Revocation List (CRL) setting allows you to specify a CRL that the BIG-IP will use to check revocation status of a certificate prior to authenticating a client. If you want to use a CRL, you must upload it to the /config/ssl/ssl.crl directory on the BIG-IP. The name of the CRL file may then be entered in the CRL setting dialog box. Note that this box will offer no drop down menu options until you upload a CRL file to the BIG-IP. Since CRLs can quickly become outdated, you should use either OCSP or CRLDP profiles for more robust and current verification functionality. Conclusion Well, that wraps up our discussion on Client Authentication. I hope the information helped, and I hope you can use this to configure your BIG-IP to meet the needs of your specific network environment. Be sure to come back for our next article in the SSL series. As always, if you have any other questions, feel free to post a question here or Contact Us directly. See you next time!SSL Profiles Part 4: Cipher Suites
Introduction This is part 4 in a series of articles covering the BIG-IP LTM SSL profiles. SSL Overview and Handshake SSL Certificates Certificate Chain Implementation Cipher Suites SSL Options SSL Renegotiation Server Name Indication Client Authentication Server Authentication All the "Little" Options We’re working our way through the profile options, and this week, we’re taking a look at the SSL ciphers. What is a Cipher Suite? A cipher suite is a set of ciphers used in the privacy, authentication, and integrity of data passed between a server and client in an SSL session. Any given session uses one cipher, which is negotiated in the handshake. The components of the cipher are Key Exchange Algorithm (RSA or DH) – symmetric (same key for encryption/decryption) or asymmetric (shared public key for encryption, protected private key for decryption) Authentication Algorithm (RSA or DSS. Note that with RSA, Key Exchange and Authentication are combined) – Used for authenticating the server and/or client. X.509 certificates in the case of SSL. Encryption Algorithm (DES, 3DES, AES, RC4) – Used to encrypt the message payload Message Authentication Code (MAC) Digest Algorithm (MD5, SHA-1) – Used for message integrity So in looking at the ciphers on my v10.2 box: [root@golgotha:LICENSE EXPIRED] config # tmm --clientciphers 'DEFAULT' ID SUITE BITS PROT METHOD CIPHER MAC KEYX 0: 5 RC4-SHA 128 SSL3 Native RC4 SHA RSA 1: 5 RC4-SHA 128 TLS1 Native RC4 SHA RSA 2: 47 AES128-SHA 128 SSL3 Native AES SHA RSA 3: 47 AES128-SHA 128 TLS1 Native AES SHA RSA 4: 47 AES128-SHA 128 DTLS1 Native AES SHA RSA 5: 53 AES256-SHA 256 SSL3 Native AES SHA RSA 6: 53 AES256-SHA 256 TLS1 Native AES SHA RSA 7: 53 AES256-SHA 256 DTLS1 Native AES SHA RSA 8: 10 DES-CBC3-SHA 192 SSL3 Native DES SHA RSA 9: 10 DES-CBC3-SHA 192 TLS1 Native DES SHA RSA 10: 10 DES-CBC3-SHA 192 DTLS1 Native DES SHA RSA You can see that for the AES256-SHA cipher, key exchange & authentication are RSA, encryption is AES, and the mac is SHA-1. Notice that all the MD5 ciphers are missing? Beginning in v10.2, all the MD5 ciphers are removed by default. You can still use them, but you’ll need to make some changes to your cipher list. Larger key lengths (256 versus 128) makes for more complicated math and is thus a) harder to crack and b) more CPU intensive. Thankfully, all BIG-IP platforms (with LTM VE the obvious exception) have hardware offloading of this processing. You’ll want to be careful in the ciphers you offer, however, as some are not fully offloaded. The list is provided in solution 6739, which is referenced below in the resources section. Setting the Cipher Options in the profile The Ciphers field in the SSL profile by default has a single word: DEFAULT. DEFAULT means different things in different versions. If you want to avoid surprises when upgrading, you might consider specifying your parameters. The table below shows the variances in *DEFAULT* behavior between versions v9.4.x – v10.0.1 DEFAULT !SSLv2:ALL:!ADH:@SPEED v10.1.x DEFAULT !SSLv2:ALL:!DH:!ADH:!EDH:@SPEED v10.2.x DEFAULT !SSLv2:ALL:!DH:!ADH:!EDH:!MD5:!EXPORT:!DES:@SPEED This shows the progression through versions. First, EDH ciphers were eliminated, then in v10.2, low strength and MD5 ciphers were eliminated. Also, notice that @SPEED keyword? That will order all the ciphers by speed. If you desire the order to be by strongest cipher instead, you can use the @STRENGTH keyword. As for the format of the list itself, the cipher strings should be separated by colons and can feature the accepted cipher strings (listed here) and these formatting options: “!” – these ciphers are permanently deleted from the list and cannot reappear in the list even if explicitly stated. “-“ - these ciphers are deleted from the list but can be re-added by later options “+” – these ciphers are moved to the end of the list. Examples So if you wanted to use the v10.2 default but order by strength instead of speed, you could use this string: [root@golgotha:LICENSE EXPIRED] config # tmm --clientciphers '!SSLv2:ALL:!DH:!ADH:!EDH:!MD5:!EXPORT:!DES:@STRENGTH' ID SUITE BITS PROT METHOD CIPHER MAC KEYX 0: 53 AES256-SHA 256 SSL3 Native AES SHA RSA 1: 53 AES256-SHA 256 TLS1 Native AES SHA RSA 2: 53 AES256-SHA 256 DTLS1 Native AES SHA RSA 3: 10 DES-CBC3-SHA 192 SSL3 Native DES SHA RSA 4: 10 DES-CBC3-SHA 192 TLS1 Native DES SHA RSA 5: 10 DES-CBC3-SHA 192 DTLS1 Native DES SHA RSA 6: 5 RC4-SHA 128 SSL3 Native RC4 SHA RSA 7: 5 RC4-SHA 128 TLS1 Native RC4 SHA RSA 8: 47 AES128-SHA 128 SSL3 Native AES SHA RSA 9: 47 AES128-SHA 128 TLS1 Native AES SHA RSA 10: 47 AES128-SHA 128 DTLS1 Native AES SHA RSA Limiting only the high security ciphers and preventing any of the SSLv2 ciphers and any ciphers without authentication or encryption, while ordering by strength: [root@golgotha:LICENSE EXPIRED] config # tmm --clientciphers 'TLSv1+HIGH:!SSLv2:!aNULL:!eNULL:@STRENGTH' ID SUITE BITS PROT METHOD CIPHER MAC KEYX 0: 53 AES256-SHA 256 TLS1 Native AES SHA RSA 1: 58 ADH-AES256-SHA 256 TLS1 Compat AES SHA ADH 2: 55 DH-RSA-AES256-SHA 256 TLS1 Compat AES SHA DH/RSA 3: 57 DHE-RSA-AES256-SHA 256 TLS1 Compat AES SHA EDH/RSA 4: 10 DES-CBC3-SHA 192 TLS1 Native DES SHA RSA 5: 27 ADH-DES-CBC3-SHA 192 TLS1 Compat DES SHA ADH 6: 16 DH-RSA-DES-CBC3-SHA 192 TLS1 Compat DES SHA DH/RSA 7: 22 DHE-RSA-DES-CBC3-SHA 192 TLS1 Compat DES SHA EDH/RSA Testing Once the cipher list is established,I can test from the command line utilizing the s_client option in the openssl command: [root@golgotha:Active] config # openssl s_client -cipher 'AES256-SHA' -connect 10.10.20.112:443 CONNECTED(00000003) depth=0 /C=US/ST=IL/L=test/O=test/OU=test/CN=test.testco.com verify error:num=18:self signed certificate verify return:1 depth=0 /C=US/ST=IL/L=test/O=test/OU=test/CN=test.testco.com verify return:1 --- Certificate chain 0 s:/C=US/ST=IL/L=test/O=test/OU=test/CN=test.testco.com i:/C=US/ST=IL/L=test/O=test/OU=test/CN=test.testco.com --- Server certificate -----BEGIN CERTIFICATE----- MIICNjCCAZ+gAwIBAgIBADANBgkqhkiG9w0BAQUFADBhMQswCQYDVQQGEwJVUzEL MAkGA1UECBMCSUwxDTALBgNVBAcTBHRlc3QxDTALBgNVBAoTBHRlc3QxDTALBgNV BAsTBHRlc3QxGDAWBgNVBAMTD3Rlc3QudGVzdGNvLmNvbTAeFw0xMDA5MjcxOTUx MTBaFw0xMTA5MjcxOTUxMTBaMGExCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJJTDEN MAsGA1UEBxMEdGVzdDENMAsGA1UEChMEdGVzdDENMAsGA1UECxMEdGVzdDEYMBYG A1UEAxMPdGVzdC50ZXN0Y28uY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB gQDgHNoyzfUUwchuLfUfj8cJKISY8v8LBQ8NhzK3sO4GSi9K/iHP4n6X2b4XsN3S 288py0H6w10kNXQBu9yCT0SZHlJl5aZ9BTxCupAwu356W4nc1YEzXb6YgIoPLdU7 S+rOIekjSVbij+vES42v7A91wlw8kTxSSfwv5NxhHgseIQIDAQABMA0GCSqGSIb3 DQEBBQUAA4GBALoT8R3Bz2ZSWGjnTAOT07W13aYdMO5lcyQ05uurL/X0SooN4jes 4a4+/pyqHw2owZzmTxUiRxLIAw49lLzhyme38egOIx6svwPl05KcpfHbaoXJEfKx PDGAOHGNxRmDuvMVNGGmdBtXmlRokEqzHAbJTHQZLOWQwuiCM8NcTIF3 -----END CERTIFICATE----- subject=/C=US/ST=IL/L=test/O=test/OU=test/CN=test.testco.com issuer=/C=US/ST=IL/L=test/O=test/OU=test/CN=test.testco.com --- No client certificate CA names sent --- SSL handshake has read 732 bytes and written 244 bytes --- New, TLSv1/SSLv3, Cipher is AES256-SHA Server public key is 1024 bit Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher : AES256-SHA Session-ID: 9ECE925CED90B4CF2EA2E8D2DD62FDCF40D8A1BF4E7A3A24588BC5A7AB21221B Session-ID-ctx: Master-Key: 55C17443918E9B8B0B15443C37DD4B3C6A7E8EDF6F2E77EA4CC3BD4E9E5682F7700DDCFDDBB3F10CD7E6B13FD60EB836 Key-Arg : None Start Time: 1292452103 Timeout : 300 (sec) Verify return code: 18 (self signed certificate) You can see that the cipher I selected from the client (the only one the client would accept) is utilized for the active session. Now, if I make a request utilizing an MD5 cipher, it errors out if (as in this case) the default v10.2 cipher list is in place: [root@golgotha:Active] config # openssl s_client -cipher 'RC4-MD5' -connect 10.10.20.112:443 CONNECTED(00000003) 20193:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:578: Important Resources I’ve drawn from several solutions over at MyF5, here’s the short list: Default Cipher Suites in version 9.2x – 9.4.x: Solution 8800 Default Cipher Suites in version 10.x: Solution 10262 Ciphers fully hardware accelerated: Solution 6739 Cipher SSL profile reference: Solution 8802 Cipher Strength reference: Solution 7815 MD5 Ciphers removed in version 10.2: Solution 11624 Conclusion There’s a lot going on with ciphers, and any one article can’t do them justice. I didn’t even approach the discussion of why certain ciphers are good/bad/ugly. A study on cryptography is out of scope, and I’m not an authority in that area any. That said, the SSL profiles are extremely flexible in allowing cipher configurations of your choice, per virtual if desired. In the next article, we’ll move another checkbox down the profile and take a look at the SSL options field.SSL Profiles Part 3: Certificate Chain Implementation
This is part 3 in a series of articles covering the BIG-IP LTM SSL profiles. SSL Overview and Handshake SSL Certificates Certificate Chain Implementation Cipher Suites SSL Options SSL Renegotiation Server Name Indication Client Authentication Server Authentication All the "Little" Options Introduction Now that we have some foundational information in place, we’ll put some of the certificate knowledge into practice as we build our first SSL profile. Recall from part 2 the certificate chain and the layers of trust involved. For our configuration (see Figure 1), I’ve built a root CA with two layers of subordinate CAs prior to actually signing a certificate for test site devcentral.f5test.com. So after much openssl cli typing (or if you are lazy like me, using TinyCA2), I end up with four files that will assist in building out our first profile: Root Certificate (dcrootCA-cacert.pem) Sub CA 1 (dcsubCA1-cacert.pem) Sub CA 2 (dcsubCA2-cacert.pem) Server Certificate (dctest.p12) Importing Certificates & Constructing the Certificate Chain The goal here is to install the root certificate on the client, and then chain the two subordinate CA certificates with the root CA for use on the profile with the server certificate. First, we’ll import the server certificate as shown in Figures 2 and 3. Beginning in version 10.1, you can import a PKCS package that includes server/key so I exported from TinyCA2 that way to save me a step. Prior to 10.1, you’ll need PEM. Now that the server certificate is in place, I can upload the CA certificates and concatenate them into a certificate chain. [root@golgotha:Active] ssl.crt # cat dcsubCA1-cacert.pem dcsubCA2-cacert.pem dcrootCA-cacert.pem > /config/ssl/ssl.crt/dctestchain.crt Next, verify that the certificate chain establishes the trust relationships for the server certificate: [root@golgotha:Active] ssl.crt # openssl verify -CAfile dctestchain.crt devcentral.f5test.com.crt devcentral.f5test.com.crt: OK On the client side, my windows 7 pc doesn’t recognize pem format, so I convert from pem to crt and scp it from the LTM and install it into my trusted root certificate authorities store: [root@golgotha:Active] tmp # openssl x509 -in dcrootCA-cacert.pem -outform DER -out dcrootCA.crt A Beginning ClientSSL Profile There are plenty of settings in the profile that we’ll get to eventually, but for our first profile, we’re going to simply reference our certificate, key, and chain. This is shown in Figure 4. Built from the clientssl default profile, we’ll name it the common name of our server, devcentral.f5test.com, then match the appropriate certificate and key we imported, and finally, we’ll need to switch to the advanced configuration to get to the chain option, where we’ll select the dctestchain certificate. After saving the profile, apply it against a virtual server and create a host entry in your hosts file to test everything out. If the trust is correct, there will be no certificate warning, as is the case shown in Figure 5 below. If we make one change to the clientssl profile and disable the certificate chain, you can see that it breaks the trust relationship (Figure 6) Gotchas There are a couple solutions on MyF5that might impact your use of certificate chains Solution 7788 – SSL certificate chains and COMPAT ciphers do not include the chain certificates specified in the SSL profile Solution 8653 – A large number of certificates in a certificate chain may cause the SSL connection to close Conclusion Whether you are using a CA-provided chain or creating your own, we’ve taken the theory of certificate chains and configured a practical example of the trust relationships in building our first clientssl profile. In the next article in this series, we’ll take a look at ciphers.SSL Profiles Part 5: SSL Options
Several months ago (ok, maybe lots and lots of months ago), Jason Rahmwrote a great series of Tech Tips that cover the BIG-IP LTM SSL profiles. SSL Overview and Handshake SSL Certificates Certificate Chain Implementation Cipher Suites SSL Options SSL Renegotiation Server Name Indication Client Authentication Server Authentication All the "Little" Options I'd like to take the baton and run a little further with the work he started. This next SSL profile article will dive into the specifics of the SSL Options that are offered in the BIG-IP LTM. Why All The Options? The LTM provides options for both client-side SSL and server-side SSL. So, why is it necessary to offer all these options? As you know, Internet browsers, operating systems, encryption algorithms, etc. sometimes have a hard time with compatibility and bugs. What!?!? Well, this is certainly true for SSL implementation. The LTM allows the behavior of the SSL library to be changed by setting several options. In order to keep traffic flowing as smoothly and efficiently as possible, the LTM is built with several OpenSSL-supported options that allow you to configure workarounds for defects and other unique settings. You can enable these workarounds and options as settings of an individual Client-side or Server-side SSL profile. This article will explore the details of what these options are and what they all mean. The following screenshot shows the location where you can enable or disable the various SSL options (navigate to Local Traffic > Profiles > SSL > Client | Server). The default value for the Options setting is Options List. Keeping this default value enables only one option: Don't insert empty fragments. As a reminder, when you enable the BIG-IP system to manage Client-side SSL traffic, the LTM terminates incoming SSL connections by decrypting the client request. The LTM then sends the request, in clear text, to a target server. Next, the LTM retrieves a clear-text response from the server and encrypts the request before sending the response back to the client. When you enable management of Server-side SSL traffic, the LTM re-encrypts a decrypted client request before sending it on to a target server. Now, let's check out the Client-side and Server-side options... Client-side Options The following is a complete list and description of the SSL Client-side options that the LTM offers. It's important for each admin to enable/disable these options based on their specific network needs. Netscape reuse cipher change bug workaround: This option handles a defect within Netscape-Enterprise Server 2.0.1. This defect only appears when connecting through SSLv2/v3 then reconnecting through SSLv3. If/when you connect this way, the cipher list changes. Initially, a connection is established with the RC4-MD5 cipher list. If the connection is resumed, it switches to the DES-CBC3-SHA cipher list. As a workaround, you can attempt to connect with a cipher list of DES-CBC-SHA:RC4-MD5 and so forth. Each new connection uses the RC4-MD5 cipher list, but any reconnection attempts use the DES-CBC-SHA cipher list. So when reconnecting, Netscape-Enterprise Server 2.0.1 always uses the first cipher in the cipher list. (Important note: as of OpenSSL 0.9.8q and 1.0.0c, this option has no effect) Microsoft big SSLv3 buffer: Some Microsoft applications (old versions of Internet Explorer) use SSLv3 packets that are greater than 18k+5 bytes. This is prohibited by the SSLv3 specification. The big SSLv3 buffer option enables a workaround for communicating with these older Microsoft applications. Microsoft IE SSLv2 RSA padding: Similar to the SSLv3 buffer, this option enables a workaround for communicating with older Microsoft IE versions that use non-standard RSA key padding. SSLeay 080 client DH bug workaround: This option enables a workaround for communicating with older SSLeay-based applications (version 0.8.0) that specify an incorrect Diffie-Hellman public key length. TLS D5 bug workaround: This option is a workaround for communicating with older TLSv1-enabled applications that specify an incorrect encrypted RSA key length. TLS block padding bug workaround: This option enables a workaround for communicating with older TLSv1-enabled applications that use incorrect block padding. No session resumption on renegotiation: This option specifies that, when the LTM performs renegotiation as an SSL server, it always starts a new session (e.g. session resumption requests are only accepted in the initial handshake). Single DH use: This option creates a new key when using ephemeral (temporary) Diffie-Hellman parameters. This option is necessary if you want to prevent small subgroup attacks when the Diffie-Hellman parameters were not generated using strong primes (i.e. when using DSA-parameters). Remember, the strength of the Diffie-Hellman key agreement protocol depends on the strength of the prime number used to generate the shared secret key. If strong primes were used, you don't have to generate a new Diffie-Hellman key during each handshake, but it's highly recommend that you do. You should enable the Single DH use option whenever ephemeral Diffie-Hellman parameters are used. Update note: The Single DH use can be effective when mitigating the Logjam vulnerability. See this article for more information. Ephemeral RSA: This option uses ephemeral (temporary) RSA keys during RSA operations (for more information on the RSA encryption algorithm, see the References section below). This is done when an RSA key can only be used for signature operations (more specifically under export ciphers with restricted RSA key length). By setting this option, the LTM always uses ephemeral RSA keys. This option breaks compatibility with the SSL/TLS specifications and can lead to interoperability problems with clients, so it's not recommended. Use it if you must, but if you can avoid it, it's recommended that you use ciphers with ephemeral Diffie-Hellman (EDH) key exchange instead. Cipher server preference: When the BIG-IP system chooses a cipher, this option uses the server's preferences instead of the client preferences. When this option is not set, the SSL server always follows the clients preferences. When this option is set, the SSLv3/TLSv1 server chooses by using its own preferences. For SSLv2, the server sends its list of preferences to the client, and the client always chooses the cipher. TLS rollback bug workaround: This option disables version rollback attack detection. During the client key exchange, the client must send the same information about acceptable SSL/TLS protocol levels as it sends during the first hello. Some clients violate this rule by adapting to the server's answer. For example, the client sends an SSLv2 hello and accepts up to SSLv3.1 (TLSv1), but the server only understands up to SSLv3. In this case, the client must still use the same SSLv3.1 (TLSv1) announcement. Some clients step down to SSLv3 with respect to the server's answer and violate the version rollback protection. No SSLv1 This options disallows the use of the SSLv1 protocol. No SSLv2 This options disallows the use of the SSLv2 protocol. No SSLv3 This options disallows the use of the SSLv3protocol. No TLSv1: This options disallows the use of the TLSv1 protocol. PKCS1 check 1: This debugging option deliberately manipulates the PKCS1 padding used by SSL clients in an attempt to detect SSL server vulnerabilities. The SSLv3 specifications require that a modified PKCS1 padding be used in the RSA encryption operation to facilitate detection of rollback attacks against SSLv3 capable browsers when using the compatibility mode. Microsoft clients do not check for the modified PKCS1 packets, so they are vulnerable to this type of attack. This option is not recommended for normal use. The system ignores this option for client-side SSL processing. PKCS1 check 2: This debugging option deliberately manipulates the PKCS1 padding used by SSL clients in an attempt to detect particular SSL server vulnerabilities. This option is not recommended for normal use. The system ignores this option for client-side SSL processing. Netscape CA DN bug workaround: This option handles a defect regarding system instability. The system crashes or hangs if the following conditions are met: 1) the system accepts a Netscape browser connection, 2) the system demands a client certificate, 3) the system has a non-self-signed CA that does not have its CA in Netscape, and 4) the browser has a certificate. This option is in place to ensure the system does not crash or hang. Netscape demo cipher change bug workaround: This option deliberately manipulates the SSL server session resumption behavior to mimic that of certain Netscape servers (see the Netscape reuse cipher change bug workaround description). This option is not recommended for normal use, and it is ignored for Server-side SSL processing. Don't insert empty fragments: This option disables a countermeasure against a SSL 3.0/TLS 1.0 protocol vulnerability affecting Cipher Block Chaining (CBC) ciphers. These ciphers cannot be handled by certain broken SSL implementations. This option has no effect for connections using other ciphers. This is the default value for the Enabled Options list (see screenshot above). Server-side Options The following is a complete list of the SSL Server-side Options: Microsoft session ID bug: This option handles the following problem with Microsoft session ID: When using SSLv2, if session-id reuse is performed, the session-id passed back in the server-finished message is different from the one decided upon. Netscape challenge bug workaround: This option handles the following Netscape challenge problem: When Netscape-Commerce v1.12 is using SSLv2, it accepts a 32-byte challenge but then appears to only use 16 bytes when generating the encryption keys. Using 16 bytes is acceptable per the encryption standard, but it should be allowed to use 32 bytes for generating the key. According to the SSLv3 specification, you should use 32 bytes for the challenge when operating in SSLv2/3 compatibility mode. But, since the 32 byte key generation breaks this server, 16 bytes is the recommended way to go. SSLRef2 reuse cert type bug workaround: This option handles the following SSL re-use certificate type problem: If R_SSL_reuse() is true, then the CERTIFICATE-TYPE, CERTIFICATE-LENGTH and CIPHER-SPECS-LENGTH fields should be 0. Some Netscape web servers do not implement this correctly. Microsoft big SSLv3 buffer: Some Microsoft applications (old versions of Internet Explorer) use SSLv3 packets that are greater than 18k+5 bytes. This is prohibited by the SSLv3 specification. The big SSLv3 buffer option enables a workaround for communicating with these older Microsoft applications. TLS block padding bug workaround: This option enables a workaround for communicating with older TLSv1-enabled applications that use incorrect block padding Passive close: This option either enables or disables the All Bugfixes Enabled option. Single DH use: This option creates a new key when using ephemeral (temporary) Diffie-Hellman parameters. This option is necessary if you want to prevent small subgroup attacks when the Diffie-Hellman parameters were not generated using strong primes (i.e. when using DSA-parameters). Remember, the strength of the Diffie-Hellman key agreement protocol depends on the strength of the prime number used to generate the shared secret key. If strong primes were used, you don't have to generate a new Diffie-Hellman key during each handshake, but it's highly recommend that you do. You should enable the Single DH use option whenever ephemeral Diffie-Hellman parameters are used. Update note:TheSingle DH usecan be effective when mitigating the Logjam vulnerability. Seethis articlefor more information. Cipher server preference: When the BIG-IP system chooses a cipher, this option uses the server's preferences instead of the client preferences. When this option is not set, the SSL server always follows the clients preferences. When this option is set, the SSLv3/TLSv1 server chooses by using its own preferences. For SSLv2, the server sends its list of preferences to the client, and the client always chooses the cipher. No SSLv1 This options disallows the use of the SSLv1 protocol. No SSLv2 This options disallows the use of the SSLv2 protocol. No SSLv3 This options disallows the use of the SSLv3protocol. No TLSv1: This options disallows the use of the TLSv1 protocol. PKCS1 check 1: This debugging option deliberately manipulates the PKCS1 padding used by SSL clients in an attempt to detect SSL server vulnerabilities. The SSLv3 specifications require that a modified PKCS1 padding be used in the RSA encryption operation to facilitate detection of rollback attacks against SSLv3 capable browsers when using the compatibility mode. Microsoft clients do not check for the modified PKCS1 packets, so they are vulnerable to this type of attack. This option is not recommended for normal use. The system ignores this option for client-side SSL processing. PKCS1 check 2: This debugging option deliberately manipulates the PKCS1 padding used by SSL clients in an attempt to detect particular SSL server vulnerabilities. This option is not recommended for normal use. The system ignores this option for client-side SSL processing. Don't insert empty fragments: This option disables a countermeasure against a SSL 3.0/TLS 1.0 protocol vulnerability affecting Cipher Block Chaining (CBC) ciphers. These ciphers cannot be handled by certain broken SSL implementations. This option has no effect for connections using other ciphers. This is the default value for the Enabled Options list (see screenshot above). Conclusion When configuring protocol versions, you must ensure that the protocol versions configured for the BIG-IP system match those of the systems peer. So, protocol versions specified in the Client-side SSL profile must match those of the client, and protocol versions specified in the Server-side SSL profile must match those of the server. Also, as stated earlier, be sure to test each option on your network before you fully implement any/all of them. But, once you know which options to employ, take full advantage of the LTM's ability to provide these great features! Well, that does it for SSL Options. The next article in this series will focus on SSL renegotiation and some of the attacks that are associated with it. References I used several sources when researching this article...here's a list of some that you might enjoy referencing: AskF5 SSL Profiles Document: http://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/ltm_concepts_11_0_0/ltm_ssl_profiles.html?sr=29775670 OpenSSL SSL_CTX_set_options: http://www.openssl.org/docs/ssl/SSL_CTX_set_options.html#DESCRIPTION SSL implementation bugs: http://www.dcs.ed.ac.uk/home/crypto/SSLeay/vendor-bugs.html Diffie Hellman encryption protocol: http://www.rsa.com/rsalabs/node.asp?id=2248 RSA encryption documents (to include PKCS #1): http://www.rsa.com/rsalabs/node.asp?id=2422 Cipher Block Chaining description: http://www.rsa.com/rsalabs/node.asp?id=2171 (updated May, 2015) Remediating Logjam: https://devcentral.f5.com/s/articles/remediating-logjam-an-irule-countermeasureSSL Profiles Part 1: Handshakes
This is the first in a series of tech tips on the F5 BIG-IP LTM SSL profiles. SSL Overview and Handshake SSL Certificates Certificate Chain Implementation Cipher Suites SSL Options SSL Renegotiation Server Name Indication Client Authentication Server Authentication All the "Little" Options SSL, or the Secure Socket Layer, was developed by Netscape back in the ‘90s to secure the transport of web content. While adopted globally, the standards body defined the Transport Layer Security, or TLS 1.0, a few years later. Commonly interchanged in discussions, the final version of SSL (v3) and the initial version of TLS (v1) do not interoperate, though TLS includes the capabality to downgrade to SSLv3 if necessary. Before we dive into the options within the SSL profiles, we’ll start in this installment with a look at the SSL certificate exchanges and take a look at what makes a client versus a server ssl profile. Server-Only Authentication This is the basic TLS handshake, where the only certificate required is on the serverside of the connection. The exchange is shown in Figure 1 below. In the first step. the client sends a ClientHello message containing the cipher suites (I did a tech tip a while back on manipulating profiles that has a good breakdown of the fields in a ClientHello message), a random number, the TLS version it supports (highest), and compression methods. The ServerHello message is then sent by the server with the version, a random number, the ciphersuite, and a compression method from the clients list. The server then sends its Certificate and follows that with the ServerDone message. The client responds with key material (depending on cipher selected) and then begins computing the master secret, as does the server upon receipt of the clients key material. The client then sends the ChangeCipherSpec message informing the server that future messages will be authenticated and encrypted (encryption is optional and dependent on parameters in server certificate, but most implementations include encryption). The client finally sends its Finished message, which the server will decrypt and verify. The server then sends its ChangeCipherSpec and Finished messages, with the client performing the same decryption and verification. The application messages then start flowing and when complete (or there are SSL record errors) the session will be torn down. Question—Is it possible to host multiple domains on a single IP and still protect with SSL/TLS without certificate errors? This question is asked quite often in the forums. The answer is in the details we’ve already discussed, but perhaps this isn’t immediately obvious. Because the application messages—such as an HTTP GET—are not received until AFTER this handshake, there is no ability on the server side to switch profiles, so the default domain will work just fine, but the others will receive certificate errors. There is hope, however. In the TLSv1 standard, there is an option called Server Name Indication, or SNI, which will allow you to extract the server name and switch profiles accordingly. This could work today—if you control the client base. The problem is most browsers don’t default to TLS, but rather SSLv3. Also, TLS SNI is not natively supported in the profiles, so you’ll need to get your hands dirty with some serious iRule-fu (more on this later in the series). Anyway, I digress. Client-Authenticated Handshake The next handshake is the client-authenticated handshake, shown below in Figure 2. This handshake adds a few steps (in bold above), inserting the CertificateRequest by the server in between the Certificate and ServerHelloDone messages, and the client starting off with sending its Certificate and after sending its key material in the ClientKeyExchange message, sends the CertificateVerify message which contains a signature of the previous handshake messages using the client certificate’s private key. The server, upon receipt, verifies using the client’s public key and begins the heavy compute for the master key before both finish out the handshake in like fashion to the basic handshake. Resumed Handshake Figure 3 shows the abbreviated handshake that allows the performance gains of not requiring the recomputing of keys. The steps passed over from the full handshake are greyed out. It’s after step 5 that ordinarily both server and client would be working hard to compute the master key, and as this step is eliminated, bulk encryption of the application messages is far less costly than the full handshake. The resumed session works by the client submitting the existing session ID from previous connections in the ClientHello and the server responding with same session ID (if the ID is different, a full handshake is initiated) in the ServerHello and off they go. Profile Context As with many things, context is everything. There are two SSL profiles on the LTM, clientssl and serverssl. The clientssl profile is for acting as the SSL server, and the serverssl profile is for acting as the SSL client. Not sure why it worked out that way, but there you go. So if you will be offloading SSL for your applications, you’ll need a clientssl profile. If you will be offloading SSL to make decisions/optimizations/inspects, but still require secured transport to your servers, you’ll need a clientssl and a serverssl profile. Figure 4 details the context. Conclusion Hopefully this background on the handshake process and the profile context is beneficial to the profile options we’ll cover in this series. For a deeper dive into the handshakes (and more on TLS), you can check out RFC 2246 and this presentation on SSL and TLS cryptography. Next up, we’ll take a look at Certificates.SSL Profiles Part 7: Server Name Indication
This is the seventh article in a series of Tech Tips that highlight SSL Profiles on the BIG-IP LTM. The other articles are: SSL Overview and Handshake SSL Certificates Certificate Chain Implementation Cipher Suites SSL Options SSL Renegotiation Server Name Indication Client Authentication Server Authentication All the "Little" Options This article will discuss the concept of Server Name Indication (SNI) and how the BIG-IP system allows you to configure it for your environment. What is Server Name Indication? SNI (listed in RFC 4366) is an extension to the TLS protocol that allows the client to include the requested hostname in the first message of the SSL handshake (Client Hello). This allows the server to determine the correct named host for the request and setup the connection accordingly from the start. Prior to the introduction of SNI, the client could not establish secure connections to multiple virtual servers hosted on a single IP address. This happened because the destination server name can only be decoded from the HTTP request header after the SSL connection has been established. As you can see from the following diagram (taken from Jason Rahm's first articlein this series), the standard TLS handshake involves several messages between the client and the server. The server sends the certificate (step 3) to the client long before the handshake is complete. If a web server is used to host multiple DNS hostnames on a single IP address, the certificate passing between the server and the client could get problematic. Using the standard TLS protocol, the server might send the wrong certificate to the client because it does not yet know which certificate the client is looking for. Then, if the client receives a certificate with the wrong name, it will either abort the connection (assuming a Man-in-the-Middle attack) or at least display a warning page to the user stating that there is a problem with the certificate. This scenario is shown in the following figure. A client wants to visit https://www.securesite1.com, but the virtual web server doesn't know to pass the certificate for securesite1.com until it finishes the TLS handshake and reads the HTTP request header from the client. This is where SNI comes in really handy. With the introduction of SNI, the client can indicate the name of the server to which he is attempting to connect as part of the "Client Hello" message in the handshake process. The server then uses this information to select the appropriate certificate to return to the client when it sends back the "Server Hello" packet during the handshake. This allows a server to present multiple certificates on the same IP address and port number and thus allows multiple secure (HTTPS) sites to be served off the same IP address without requiring all the sites to use the same certificate. Having this extension available (per RFC 4366) is a great feature, but it does no good if a client is using a browser that doesn't send the correct SNI message to the server. So, to make SNI practical, the vast majority of your users must use web browsers that support it. Browsers that do not support SNI will be presented with the server's default certificate and are likely to receive a certificate warning. According to Wikipedia, the following browsers support SNI: Internet Explorer 7 or later, on Windows Vista or higher. Does not work on Windows XP, even Internet Explorer 8 (the support of this feature is not browser version dependent, it depends on SChannel system component which introduced the support of TLS SNI extension, starting from Windows Vista, not XP). Mozilla Firefox 2.0 or later Opera 8.0 (2005) or later (the TLS 1.1 protocol must be enabled) Opera Mobile at least version 10.1 beta on Android Google Chrome (Vista or higher. XP on Chrome 6 or newer. OS X 10.5.7 or higher on Chrome 5.0.342.1 or newer) Safari 3.0 or later (Mac OS X 10.5.6 or higher and Windows Vista or higher) Konqueror/KDE 4.7 or later MobileSafari in Apple iOS 4.0 or later Android default browser on Honeycomb (v3.x) or newer Windows Phone 7 MicroB on Maemo Odyssey on MorphOS Now that you know the background of SNI, let's dig into how the BIG-IP is set up for SNI configuration. BIG-IP Configuration Beginning in v11.1.0, the BIG-IP allows you to assign multiple SSL profiles to a virtual server for supporting the use of the TLS SNI feature. The TLS SNI feature is not available in previous BIG-IP versions, so you'll want to upgrade if you are not on v11.1.0 or higher! To support this feature, a virtual server must be assigned a default SSL profile for fallback as well as one SSL profile per HTTPS site. The fallback SSL profile is used when the server name does not match the client request or when the browser does not support the SNI extensions. Using the example from the figures above, suppose you need to host the three domains securesite1.com, securesite2.com, and securesite3.com on the same HTTPS virtual server. Each domain has its own server certificate to use, such as securesite1.crt, securesite2.crt, and securesite3.crt, and each has different security requirements. To ensure that the BIG-IP presents the correct certificate to the browser, you enable SNI, which sends the name of a domain as part of the TLS negotiation. To enable SNI, you configure the Server Name and other settings on an SSL profile, and then assign the profile to a virtual server. For SSL profiles (Client and Server), you type the name for the HTTPS site in the Server Name box. SNI configuration is found by navigating to Local Traffic > Profiles > SSL > Client | Server. The following screenshot shows the three settings used for SNI in the BIG-IP. Server Name specifies the fully qualified DNS hostname of the server that is used in SNI communications. Using the server name, the Local Traffic Manager can choose from multiple SSL profiles prior to the SSL Handshake. If no value is specified, the system uses the Common Name value from the default certificate. The default for this setting leaves the name blank. Default SSL Profile for SNI indicates that the system uses this profile as the default SSL profile when there is no match to the server name, or when the client provides no SNI extension support. Note that when assigning multiple SSL profiles to a single virtual server, you can enable this setting on one Client SSL profile only and on one Server SSL profile only. The default for this setting is unchecked. Require Peer SNI support requires that all network peers provide SNI support as well. If you enable both "Default SSL Profile for SNI" and "Require Peer SNI Support," the system terminates the connection when the client provides no SNI extension. The default for this setting is unchecked. Conclusion I hope this helps with setting up this great feature in your environment. SNI is a powerful tool, and it could go a long way in saving you precious IP addresses for your secure sites! As we noted before, this feature is only supported in BIG-IP version 11.1.0 and later. If you are using a version prior to 11.1.0, you can read this articleon DevCentral that shows how you can use an iRule to take advantage of SNI on previous versions. Finally, you can read more on our DevCentral Wiki about using iRules for SNI. Well, thanks for reading about SNI. Be sure to come back for the next article in the SSL series where I will talk about SSL Forward Proxy. See you then!
