Chapter 2: SSL VPN Technology

Cisco Press

1 2 3 4 5 6 7 Page 5
Page 5 of 7
 [root@playground ~]# ssldump -ANew TCP connection #1: 10.1.1.200(46882) <-> p3.http://www.scd.yahoo.com(443)1 1 0.0172 (0.0172) C>S SSLv2 compatible client hello Version 3.1 cipher suites Unknown value 0x39 Unknown value 0x38 Unknown value 0x35 Unknown value 0x33 Unknown value 0x32 TLS_RSA_WITH_RC4_128_MD5 TLS_RSA_WITH_RC4_128_SHA Unknown value 0x2f TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA Unknown value 0xfeff TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS_DHE_RSA_WITH_DES_CBC_SHA TLS_DHE_DSS_WITH_DES_CBC_SHA Unknown value 0xfefe TLS_RSA_WITH_DES_CBC_SHA TLS_RSA_EXPORT1024_WITH_RC4_56_SHA TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA TLS_RSA_EXPORT_WITH_RC4_40_MD5 TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD51 2 0.0486 (0.0313) S>CV3.1(74) Handshake   ServerHello    Version 3.1    random[32]=     43 c0 b8 c4 3a a0 fc b6 9c cf 96 49 c9 8e 40 67     be 68 7e 1a 2f 7d 89 c0 5e 13 3c 0a eb a9 4f cb    session_id[32]=     b4 b3 a4 ac 89 46 4a db b9 04 08 65 d0 c8 16 1a     ab 68 25 91 2e 0e 31 39 1e 33 df 49 79 13 35 2d    cipherSuite     TLS_RSA_WITH_RC4_128_MD5    compressionMethod          NULL1 3 0.0486 (0.0000) S>CV3.1(761) Handshake   Certificate1 4 0.0486 (0.0000) S>CV3.1(4) Handshake   ServerHelloDone1 5 0.0554 (0.0067) C>SV3.1(134) Handshake   ClientKeyExchange    EncryptedPreMasterSecret[128]=     24 24 35 f6 e5 5f 80 d6 a0 fd 93 96 6f 09 9d dd     aa 96 d0 f5 21 40 2c f9 a8 60 f6 9b 33 8b 87 96     68 3c 7b c3 15 d1 a7 c6 99 a8 29 fd 56 fe de 65     13 d4 77 42 3c e9 50 77 73 b1 1a 18 5b f1 00 16     0c 51 3c 04 c7 fa 83 e1 ed 4d 9f ac 55 24 1c 0f     90 28 9a 25 b9 7a 80 6b 97 d1 17 56 44 c0 c1 b8     1f 6f 86 fb 04 bb 4a c2 97 c1 40 3a 4f 72 fe bc     e2 6a a0 5b ba 9a 82 79 5c e3 71 d8 44 b0 c5 4b1 6 0.0554 (0.0000) C>SV3.1(1) ChangeCipherSpec1 7 0.0554 (0.0000) C>SV3.1(32) Handshake1 8 0.0848 (0.0293) S>CV3.1(1) ChangeCipherSpec1 9 0.0848 (0.0000) S>CV3.1(32) Handshake1 10 0.0856 (0.0008) C>SV3.1(629) application_data1 11 0.1248 (0.0391) S>CV3.1(364) application_data1 12 0.1254 (0.0006) S>CV3.1(18) Alert1 13 0.1259 (0.0004) C>SV3.1(18) Alert1  0.1263 (0.0004) S>C TCP FIN1  0.1267 (0.0003) C>S TCP RST[root@playground ~]# ssldump -ANew TCP connection #1: 10.1.1.200(46882) <-> p3.http://www.scd.yahoo.com(443)1 1 0.0172 (0.0172) C>S SSLv2 compatible client hello Version 3.1 cipher suites Unknown value 0x39 Unknown value 0x38 Unknown value 0x35 Unknown value 0x33 Unknown value 0x32 TLS_RSA_WITH_RC4_128_MD5 TLS_RSA_WITH_RC4_128_SHA Unknown value 0x2f TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA Unknown value 0xfeff TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS_DHE_RSA_WITH_DES_CBC_SHA TLS_DHE_DSS_WITH_DES_CBC_SHA Unknown value 0xfefe TLS_RSA_WITH_DES_CBC_SHA TLS_RSA_EXPORT1024_WITH_RC4_56_SHA TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA TLS_RSA_EXPORT_WITH_RC4_40_MD5 TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD51 2 0.0486 (0.0313) S>CV3.1(74) Handshake   ServerHello    Version 3.1    random[32]=     43 c0 b8 c4 3a a0 fc b6 9c cf 96 49 c9 8e 40 67     be 68 7e 1a 2f 7d 89 c0 5e 13 3c 0a eb a9 4f cb    session_id[32]=     b4 b3 a4 ac 89 46 4a db b9 04 08 65 d0 c8 16 1a     ab 68 25 91 2e 0e 31 39 1e 33 df 49 79 13 35 2d    cipherSuite     TLS_RSA_WITH_RC4_128_MD5    compressionMethod          NULL1 3 0.0486 (0.0000) S>CV3.1(761) Handshake   Certificate1 4 0.0486 (0.0000) S>CV3.1(4) Handshake   ServerHelloDone1 5 0.0554 (0.0067) C>SV3.1(134) Handshake   ClientKeyExchange    EncryptedPreMasterSecret[128]=     24 24 35 f6 e5 5f 80 d6 a0 fd 93 96 6f 09 9d dd     aa 96 d0 f5 21 40 2c f9 a8 60 f6 9b 33 8b 87 96     68 3c 7b c3 15 d1 a7 c6 99 a8 29 fd 56 fe de 65     13 d4 77 42 3c e9 50 77 73 b1 1a 18 5b f1 00 16     0c 51 3c 04 c7 fa 83 e1 ed 4d 9f ac 55 24 1c 0f     90 28 9a 25 b9 7a 80 6b 97 d1 17 56 44 c0 c1 b8     1f 6f 86 fb 04 bb 4a c2 97 c1 40 3a 4f 72 fe bc     e2 6a a0 5b ba 9a 82 79 5c e3 71 d8 44 b0 c5 4b1 6 0.0554 (0.0000) C>SV3.1(1) ChangeCipherSpec1 7 0.0554 (0.0000) C>SV3.1(32) Handshake1 8 0.0848 (0.0293) S>CV3.1(1) ChangeCipherSpec1 9 0.0848 (0.0000) S>CV3.1(32) Handshake1 10 0.0856 (0.0008) C>SV3.1(629) application_data1 11 0.1248 (0.0391) S>CV3.1(364) application_data1 12 0.1254 (0.0006) S>CV3.1(18) Alert1 13 0.1259 (0.0004) C>SV3.1(18) Alert1  0.1263 (0.0004) S>C TCP FIN1  0.1267 (0.0003) C>S TCP RST

As you can see, the exchange took place exactly as the steps described in Figure 2-9, with one minor exception. Although the client browser was configured to use SSL v3 or TLS, the browser still sends an SSL v2 ClientHello to the server for backward compatibility. Note that the SSL v2 ClientHello message has a slightly different structure from that of SSL v3 and TLS. The server that usually used SSL v3 or TLS continued the exchange using TLS by sending back a TLS ServerHello. Also the server "translated" the fields in the SSL v2 ClientHello message to get TLS values, such as client.random. From the output of the ssldump, you can see that the server chose TLS as the protocol, RSA as the key exchange and authentication method, MD5 as the hashing algorithm, and 128-bit RC4 as the encryption algorithm. The client and server then went through the key exchange to establish the SSL connection after frame 9. Frames 10 and 11 are application data corresponding to an HTTP request from the client and HTTP response from the server replying to the web page. Then the client and server sent the Alert message to close the connection.

We look at this once again at the TCP/IP packet level to see the full exchange and the layout of SSL records inside TCP packets. Figure 2-10 displays the packet capture of an SSL connection.

First, frames 1 to 3 show the TCP three-way handshake that is made to establish the TCP connection over port 443 (HTTPS). From frame 4, the client (10.1.1.200) and the server (66.94.230.34) started the SSL session negotiation:

  • In frame 4, the client sent the backward-compatible SSL v2 ClientHello.

  • In frame 5, the server replied with three messages (ServerHello, Certificate, and ServerHelloDone) all in one packet.

  • In frame 7, the client sent ClientKeyExchange, ChangeCipherSpec, and ClientFinished messages in one packet. Note that as previously stated, just after the ChangeCipherSpec is sent, the subsequent data will be encrypted using the negotiated CipherSpec. That is why the ClientFinished message was shown as "Encrypted Handshake Message" in the packet capture.

Figure 2-10

Packet Capture of an SSL Connection

  • In frame 8, the server sent ChangeCipherSpec and ServerFinished encrypted with the newly negotiated keys.

  • In frames 9 and 10, the client and server exchange application data under the protection of the SSL session.

  • In frames 11 and 12, the client and the server used an Alert message to indicate the close of the SSL connection.

  • In frames 13 to 15, the client and server went through the TCP connection close phase to tear down the TCP connection.

As you just saw, the SSL client and server can send multiple records in one packet. The middle pane of Figure 2-11 provides an example of message encapsulation of SSL handshake messages, SSL records, and finally TCP/IP packets. For frame 5, in which the server replied ServerHello, Certificate, and ServerHelloDone to the client, take note of the following:

  • This example clearly shows the SSL/TLS protocol structure and its position in TCP/IP stack. The handshake protocols are at the top. Then come the SSL/TLS record protocol as the payload of the TCP, and finally you see the IP layer and Layer 2 Ethernet frame.

  • Three handshake messages are in this packet. As discussed earlier, SSL/TLS is a layered protocol in which the record protocol sits at the lowest level. You can see that in this packet, each handshake message was encapsulated in a TLS record. The Content Type field in the TLS record indicated what message type was carried.

  • The structure of one of the handshake messages, ServerHello, is shown in the display. As an exercise, you can try to match it with the ServerHello structure shown in the earlier section.

DTLS

The recent success of SSL VPN poses new challenges to the underlying SSL/TLS protocol. As a complete remote access VPN solution, the SSL VPN is required to support various types of applications. UDP applications that are based on real-time protocols, such as voice over IP (VoIP) and streaming media applications, are especially challenging to SSL/TLS.

This challenge to SSL/TLS has emerged because TLS requires a reliable data channel such as TCP, which offers reliable, in-order transmission and flow control. It cannot be used to secure datagram traffic. SSL VPN is able to tunnel the UDP applications and then transport them using the TLS connection that runs over TCP. However, the performance can be very poor, especially when SSL VPN handles real-time applications.

Consider the following scenario of transmitting VoIP traffic over the Internet that could introduce out-of-order packets, packet losses, and congestion. When the VoIP traffic is carried over SSL, the underlying TCP will try to retransmit the lost packets and apply flow control when packet losses are severe. These actions can greatly affect the delay and delay jitter of the VoIP traffic and make the user experience very poor.

Eric Rescorla and Nagendra Modadugu designed datagram TLS (DTLS) to solve the issue previously outlined by allowing TLS to run over UDP. Because TLS was originally designed to run over TCP, it has no internal facilities to handle the unreliability in a datagram environment. DTLS makes the following adjustments to the TLS protocol:

  • At the record layer, DTLS introduces two new fields, the epoch and the sequence number, as follows:

  •  struct {    ContentType type;    ProtocolVersion version;    uint16 epoch;        // New field    uint48 sequence_number;    // New field    uint16 length;    opaque fragment[DTLSPlaintext.length];    } DTLSPlaintext;struct {    ContentType type;    ProtocolVersion version;    uint16 epoch;        // New field    uint48 sequence_number;    // New field    uint16 length;    opaque fragment[DTLSPlaintext.length];    } DTLSPlaintext;

    The epoch numbers are used by the endpoint to determine which cipher state has been used to protect the record data. The sequence numbers are introduced to deal with lost and out-of-order packets. DTLS uses the same antireplay window mechanism that is used by IPsec Authentication Header (AH) or Encapsulating Security Payload (ESP).

  • At the handshake layer, DTLS uses the same handshake messages and flows as TLS, with the following additions:

    — A stateless cookie exchange is added to prevent a denial of service (DoS) attack.

    — The handshake message header is modified to add the sequence number, fragment length, and fragment offset to handle message loss, out-of-order messages, and fragmentation.

    — Retransmission timers are used on both client and server sides to handle message losses.

It is worth noting that RC4, the commonly used cipher in TLS, is not easily applied in lossy datagram traffic; hence it is not allowed to be used in DTLS.

Currently, DTLS is defined in an IETF draft, and it has been implemented as part of an open source toolkit, OpenSSL.

SSL VPN

SSL provides secure communications for applications, and it is transparent to the upper-layer applications. The most successful application running on top of SSL is HTTP because of the huge popularity of the World Wide Web. All commercial web browsers that are by default available on all operating systems now support HTTPS (HTTP over SSL/TLS). This ubiquity, if used in remote access VPNs, provides some appealing properties:

  • Secure communication using cryptographic algorithms: It offers confidentiality, integrity, and authentication.

  • Ubiquitousness: The ubiquity of SSL/TLS makes it possible for VPN users to remotely access corporate resources from anywhere using any PC, without having to preinstall a remote access VPN client.

  • Low management cost: The clientless access makes this type of remote access VPN almost deployment free and maintenance free at the end-user side. This is a huge benefit for the IT management personnel, who would otherwise spend considerable resources to deploy and maintain their remote access VPN solutions.

  • Effective operation with a firewall and NAT: SSL VPN operates on the same port as HTTPS (TCP/443). Most Internet firewalls, proxy servers, and NAT devices have been set up to handle TCP/443 traffic well. So there is no need for any special consideration to transport SSL VPN traffic over the networks. This has been viewed as a significant advantage over native IPsec VPN that operates over IP type 50 (ESP) or 51 (AH), which in many cases need special configurations on the firewall or NAT devices to let them pass through.

As SSL VPN evolves to fulfill another important requirement of remote access VPN—the requirement of supporting any application—some of these properties are no long true depending on which SSL VPN technology the VPN users choose. But overall, these properties are the main drivers for the popularity of SSL VPN in recent years and are heavily marketed by SSL VPN vendors as the main reasons for IPsec replacement.

Today, no official standard exists for SSL VPN. Today's SSL VPN technology uses SSL/TLS as secure transport and employs a heterogeneous collection of remote access technologies such as reverse proxy, tunneling, and terminal services to provide users with different types of access methods that fit different environments. The sections that follow examine some commonly used SSL VPN technologies:

  • Reverse proxy technology

  • Port-forwarding technology

  • SSL VPN tunnel client

  • Integrated terminal services

Reverse Proxy Technology

HTTPS provides secure web communication between a browser and a web server that supports the HTTPS protocol. SSL VPN extends this model to allow VPN users to access corporate internal web applications and other corporate application servers that might or might not support HTTPS, or even HTTP. SSL VPN does this by using several techniques that are collectively called reverse proxy technology.

A reverse proxy is a proxy server that resides in front of the application servers, normally web servers, and functions as an entry point for Internet users who want to access the corporate internal web application resources. To the external clients, a reverse proxy server appears to be the true web server. Upon receiving the user's web request, a reverse proxy relays the user request to the internal web server to fetch the content on behalf of the users and relays the web content to the user with or without additional processing.

Many web server implementations support reverse proxy. One example is the mod_proxy module in Apache. With so many implementations, you might wonder why you need an SSL VPN solution to have this functionality. The answer is that SSL VPN offers much more functionality than traditional reverse proxy technologies:

  • SSL VPN can transform complicated web and some nonweb applications that simple reverse proxy servers cannot handle. The content transformation process is sometimes called webification. For example, SSL VPN solutions allow users to access Windows or UNIX file systems. The SSL VPN gateway needs to be able to communicate with internal Windows or UNIX servers and webify the file access in a web browser–presentable format for the VPN users.

  • SSL VPN supports a wide range of business applications. For applications that cannot be webified, SSL VPN can use other resource access methods to support them. For users who demand ultimate access, SSL VPN can provide network-layer access to directly connect a remote system to the corporate network, in the same manner as an IPsec VPN.

  • SSL VPN provides a true remote access VPN package, including user authentication, resource access privilege management, logging and accounting, endpoint security, and user experience.

The reverse proxy mode in SSL VPN is also known as clientless web access or clientless access because it does not require any client-side agents to be installed on the client machine. Figure 2-11 shows how SSL VPN users access corporate resources using the clientless web access mode.

Figure 2-11

SSL VPN Reverse Proxy Operation

  1. The SSL VPN user connects to the SSL VPN device by entering the sign-in URL https://172.23.93.62 into the browser. The client browser and the SSL VPN device first establish an SSL connection. After user authentication at the sign-in page, the user sees the sign-in page with resource bookmarks. To access an internal web server, the user either clicks one of the bookmarks or manually enters the desired URL, in this case, http://www.cisco.com.

  2. Upon receiving the URL request, the client browser changes the requested URL to https://172.23.93.63/0/http//http://www.cisco.com/. This process is called URL mangling. According to the URL mangling rule shown in Figure 2-11, the mangled URL points to the SSL VPN gateway while preserving the original URL request information. The client browser then sends this request to the SSL VPN gateway instead of sending it directly to http://www.cisco.com.

  3. Upon receiving the request, the SSL VPN gateway restores the mangled URL to its original form. It then sends an HTTP request to the internal web server http://www.cisco.com.

  4. The internal web server returns the content to the SSL VPN gateway.

  5. The SSL VPN gateway performs content transformation, also known as content rewriting, on the server content. Then it sends the rewritten content to the client through the established SSL session.

Note the two important techniques in the previous steps: URL mangling and content rewriting. The following sections describe these techniques.

URL Mangling

Related:
1 2 3 4 5 6 7 Page 5
Page 5 of 7
SD-WAN buyers guide: Key questions to ask vendors (and yourself)