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;
- Web Client sends the request for a HTTPS/ SSL web page along with its
requirements to establish a session
- Server Responds with a certificate that meets the clients cipher and
version requirements (see the Key Agreement explanation below) where
there are two options;
- The Certificate is signed by a trusted RCA or Root Certificate
Authority
- The Certificate is signed by a non-trusted RCA and the Web Client shows
security error messages
- 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
|