High Quality
Open the downloaded document, and select print from the file menu (PDF reader required).
INSPECTING HTTPSTRAFFIC ON GATEWAYS
October 2011Author: Kishin Fatnani
This article was originally written for and published in
Exploiting Software 02/11 - Hakin9 magazine
(http://hakin9.org/)
What to expect in this article
•
Basics on Secure Sockets Layer (SSL) based communication
•
How security devices inspect Hypertext Transfer Protocol Secure (HTTPS) traffic
•
Pros and cons of enabling HTTPS inspection on Check Point R75.20
Inspecting HTTPS Traffic on Gateways by Kishin Fatnani
Blog: kishinf.blogspot.com Facebook: www.facebook.com/ksecure Twitter: www.twitter.com/ksecure
Page | 2
INTRODUCTION
In the past, security devices inspecting application content for attack patterns, misuse or malware, had beenblind to encrypted traffic and due to this encrypted protocols like Hypertext Transfer Protocol Secure (HTTPS)have been a safe method used by attackers to bypass security inspection. Though reverse proxies and WebServer modules have been there for long, but they only inspect incoming traffic i.e. connections made toprotected web servers in the organization. Inspecting outgoing traffic or traffic of connections made by usersto outside world servers, not protected by the device, had been on the wish lists. Devices these days comewith the capability to inspect Secure Sockets Layer (SSL) based outgoing traffic, however there are someconcerns enabling such kind of inspection. In this article we cover some basics of SSL, the challenges ininspecting SSL traffic, and also see how Check Point's HTTPS Inspection feature is able to inspect HTTPS trafficat the gateway. After reading this article you will know the pros and cons of enabling SSL inspection on agateway.
SECURE SOCKETS LAYER (SSL) BASICS
Protocols like HTTP, SMTP, POP3 etc are plaintext i.e. data carried by these protocols can be read by anyonewho is able to intercept the traffic while in transit. Since these protocols are widely used over the Internet,there was a need to secure them in order to protect users' data. By protection of data we are looking atconfidentiality, integrity and authentication.Instead of building security measures in all the application protocols, the Secure Sockets Layer (SSL) protocolprovides a secure channel below the application layer thereby making it easier to make an application protocola secure protocol.
Figure 1: SSL providing security below application and above transport layers
SSL is prominently used to protect the HTTP protocol making it HTTPS. Today it is also used to tunnel an entirenetwork stack, creating a VPN.The SSL specification was developed by Netscape communications. After its version 3.0, a new Internetstandard protocol was defined and called Transport Layer Security (TLS). The first version of TLS, version 1.0,was kind of an upgrade to SSL 3.0 with a few enhancements. Most web browsers and servers today supportTLS 1.0, though versions 1.1 and 1.2 were also defined later, many browsers and applications are yet tosupport them.
Throughout this article, we may commonly refer to both, SSL and TLS, as SSL.
HOW SSL/TLS WORK
SSL provides:
Confidentiality
- the data passing through SSL is encrypted using a symmetric encryption algorithmlike DES, 3DES, RC4, AES etc.
Integrity
- a hashing algorithm like MD5, SHA1 etc. is used which transforms data of any length into asmall (128.160 or 256 bits depending on the algorithm used) fixed size data called the hash. Thereceiving end would also create hash of the same data and match to verify the integrity
Authentication
- achieved by RSA signatures or DSS.
Inspecting HTTPS Traffic on Gateways by Kishin Fatnani
Blog: kishinf.blogspot.com Facebook: www.facebook.com/ksecure Twitter: www.twitter.com/ksecure
Page | 3
Key Exchange - to use symmetric encryption, the two parties, the sender and the receiver, need toshare a common secret key. Exchanging this secret key over an insecure network is a challenge assomeone acquiring the key can decipher the entire communication. For this reason, an asymmetricalgorithm is used for the key exchange which could be RSA or DH.A set of algorithms, one for each function (Confidentiality, Integrity, Authentication and Key exchange), isknown as a cipher suite. For e.g.
TLS_RSA_WITH_RC4_128_MD5TLS_RSA_WITH_RC4_128_SHATLS_DH_RSA_WITH_DES_CBC_SHATLS_DHE_DSS_WITH_DES_CBC_SHA
Given above are some of the cipher suites used in TLS. For instance the cipher suite named
TLS_DH_RSA_WITH_DES_CBC_SHA
specifies that TLS will be used with DH for key exchange, RSA forauthentication, DES_CBC for encryption and SHA for hashing.
SESSION ESTABLISHMENT
When an SSL session is initiated, the client sends its SSL version along with a list of supported cipher suites tothe server. The server chooses its preferred suite and responds back to the client. If the server does notsupport any of the suites proposed by the client, the session fails to establish.If authentication is required, the server presents its X.509 certificate to the client and it may also request theclient to send its certificate. This is not mandatory in SSL though it is very common that a server usually sendsits certificate while not requesting client's certificate for authenticating the client.
WHAT IS CHECKED IN THE CERTIFICATE?
Name
- When the server sends its certificate to the client, the client checks the domain name in thecertificate
Validity
- its date of creation and expiry are checked to see if today's date falls in between
Authority
- the most important is the authority that signed the certificate must be a trusted oneThere may be a chain of certificates including the server's certificate, then that of the authority who issued theserver's certificate followed by the issuer of the authority's certificate and so on till a root authority is reachedwhich has a self signed certificate. The client will check certificates up till it finds a trusted authority'scertificate.
WHICH AUTHORITIES DO WE TRUST?
Usually clients like web browsers come with a list of trusted authorities which can be seen in the options dialogin the browsers. Users may also add new authorities by adding their certificates.
CERTIFICATE STATUS
An authority may revoke a certificate before its expiry date for some reasons. A revoke certificate must not beaccepted by a client, hence a client needs to check the current status of the certificate by querying theCertificate Authority (CA). The CA may provide a list of revoked certificates called the CRL or it may provide anonline service, Online Certificate Status Protocol (OCSP), to check the status of the certificate. The URLs forquerying are provided in the certificate itself.
Add a Comment