DEFINITION: HTTPS (Hyper Text Transport Protocol Secure) is inside of a secure tunnel known as SSL (Secure Sockets Layer) is a way of sending data over the web that makes it very difficult for a third party "evesdropper" to view the data. This added layer of security is used by the large majority of sites that transfer data. Search engines, web based email, web apps, and any site with a login should use HTTPS/ SSL. Nearly all bot, malware, and data theft tools will use HTTPS/ SSL because network based security tools such as firewalls, malware/ virus inspection devices, Intrusion Detection & Intrusion Prevention Systems (IPS & IDS) do not (or rarely) have the ability to inspect HTTPS /SSL traffic. You may also see TLS or Transport Layer Security used along side or in place of the term SSL. TLS is simply a newer flavor of SSL.

More than %80 of all data leaks happen over HTTPS/ SSL

Both Network and Endpoint based Data Security tools should be able to detect or stop a leak over HTTPS/ SSL

Simply if the tool cannot perform HTTPS/ SSL inspection then it is not a true Data Security tool.

How TLS/ SSL (HTTPS) works (the quick basics)

Example of establishing a secure web session:

1) Browser asks for a https://dataleaktest.com

2) Dataleaktest.com responds with a signed public key

3) Browser validates the Certificate trust

        a. If there are any issues with the Certificate the browser will throw an error/ alert

4) If all is trusted then the session is established and the page is served

How TLS/ SSL (HTTPS) INSPECTION  works (the quick basics) MIM (Man In the Middle)

Example of establishing and inspecting a secure web session:

1) Browser asks for a https://dataleaktest.com

2) The browser request is intercepted by the inspection device or PROXY

        a. This traffic redirection can be a browser setting, PAC file, WCCP, etc.

3) The PROXY asks for https://dataleaktest.com

4) Dataleaktest.com responds with a signed public key

5) The PROXY validates the Certificate trust

        a. If there are any issues with the Certificate the browser will throw an error/ alert

6) If all is trusted then the session is established and the page is served to the PROXY

7) The PROXY responds to the original web request in step 1 with a locally signed Certificate

        a. The PROXY must be part of your Orgs PKI (cert trust) infrastructure or be a "Sub CA" of a CA that is trusted by  the Browser

        b. The PROXY must be a CA or Sub CA and must generate a new public key for each session or the numerous PROXIED sessions could spy on each other

8) If the root CA of the Public key served to the browser is trusted then a second TLS/ SSL session is established back to the browser/ user

        a. If the PROXY's root CA is not trusted the browser will throw an error/ alert

9) Page served to browser/ user

TLS/SSL (HTTPS) into the weeds we go...

For simplicity there are 4 major components to an HTTPS transaction;

• Web Client - the user, someone surfing the web
• Web Server - where the web content comes from. The computer the houses a particular web site or multiple web sites
• Trusted Root CA - Digitally signs Certificates that machines can trust automatically
• Certificate - The key that allows you to decode an SSL message.

SSL Handshake

Simplified 3 step SSL "handshake" where the level of security is negotiated;

1. Web Client sends the request for a HTTPS/ SSL web page along with its requirements to establish a session
2. Server Responds with a certificate that meets the clients cipher and version requirements (see the Key Agreement explanation below) where there are two options;
   1. The Certificate is signed by a trusted RCA or Root Certificate Authority
   2. The Certificate is signed by a non-trusted RCA and the Web Client shows security error messages
3. If the Certificate was signed by a trusted RCA then the session is established and all further communications are encrypted using SSL

If you wish to dive a little deeper into Crypto technology you should probably understand a few things before doing a web search because the info out there assumes you know these things;

Client/ Server Key Agreement (step 2 of the SSL handshake above expanded)

During this 3 step handshake above these are negotiated

1) Key Agreement where the Key and Cipher are agreed upon

        a. SSL/ TLS Version (SSL version 3 or TLS versions 1.0, 1.1, 1.2, and future releases are the only ones that should be used)

        b. Cipher or algorithm used some of these are Triple DES, RC4, RC2, DES, RSA

2) Certificate validation, CRL check

3) Message Authentication parameters: Session data used for session Authentication. This prevents replay attacks from a different source

How a packet from and established SSL/ TLS session looks if you think of each of the OSI model components as an envelope

( Ethernet ( IP4/6 ( TLS/SSL ( HTTP ( DATA ) HTTP ) TLS/SSL ) IP4/6 ) Ethernet)

There is a very complete write-up on HTTPS at wikipedia: http://en.wikipedia.org/wiki/Transport_Layer_Security