2015-05-04 18:56:50 +00:00
|
|
|
TLS: An examination into the Security of the Internet, Part 1
|
|
|
|
|
2015-05-04 18:52:26 +00:00
|
|
|
TLS, more often referred to as SSL, is the means by which a secure connection is
|
|
|
|
established over a computer network. Most often these connections are
|
|
|
|
established over the Internet, between a client (ex., web browser) and a server
|
|
|
|
(ex., a web site). In the specific case of web sites, HTTP is layered on TLS/SSL
|
|
|
|
to ensure a secure and private connection; HTTPS is not a separate protocol,
|
|
|
|
rather a combination or protocols. Establishing a secure connection thus
|
|
|
|
requires a few steps:
|
|
|
|
|
|
|
|
Step 1: Establish an TCP connection
|
|
|
|
TCP is a transport-layer protocol that establishes a connection which is
|
|
|
|
reliable and fault-tolerant. As opposed to UDP, TCP will seek to verify that
|
|
|
|
information is transferred successfully and as intended. This is important
|
|
|
|
for the next step. The connection is established as follows:
|
|
|
|
|
|
|
|
1. A client will contact a server and announce it wishes to establish
|
|
|
|
a connection. (Called a SYN, short for synchronize). This SYN is a
|
|
|
|
number, stored as part of the TCP header; we'll call it A.
|
|
|
|
|
|
|
|
2. The server will respond to the client announcing it has received
|
|
|
|
the client's wish, and also state that it wishes to establish a
|
|
|
|
connection. (Called a SYN-ACK, short for synchronize-acknowledge).
|
|
|
|
Ths SYN-ACK is actually two values: One is the ACK value, A+1. The
|
|
|
|
second is the server's SYN value, which we'll call B.
|
|
|
|
|
|
|
|
3. The client then acknowledged the server's wish, thus establishing a
|
|
|
|
connection (Called simply an ACK). Because it was expecting an ACK
|
|
|
|
value in step 2, and expecting that value to be A+1, it can verify
|
|
|
|
that this connection is the same as the one it started. Additionally
|
|
|
|
and similarly, the ACK which gets returned to the server as B+1.
|
|
|
|
|
|
|
|
4. At this point, the connection is established. Both client and
|
|
|
|
server have assured themselves of a proper connection thanks to the
|
|
|
|
three-way handshake described above. From this point forward, the
|
|
|
|
server has bound a specific port to listen for any further
|
|
|
|
communications with the client.
|
|
|
|
|
|
|
|
Step 2: Establish an SSL/TLS Connection
|
|
|
|
TLS, Transport Layer Security, is appropriately on the same layer as TCP,
|
|
|
|
the transport layer. TLS relies on public key authentication to establish a
|
|
|
|
secure connection between the aforementioned client and server. The
|
|
|
|
connection is established as follows:
|
|
|
|
|
|
|
|
1. A client will announce to the server it wishes to establish a
|
|
|
|
TLS/SSL connection. It will include information such as it's TLS/SSL
|
|
|
|
version, the ciphersuites it wishes to use, and which compression
|
|
|
|
methods it wishes to use.
|
|
|
|
|
|
|
|
2. The server then uses the highest possible TLS/SSL version, chooses
|
|
|
|
one of the ciphersuites available to the client, chooses one of the
|
|
|
|
compression methods available to the client, and sends it's
|
|
|
|
certificate. A certificate is basically a container for a server's
|
|
|
|
public key, but with many additional details, and often signed by a
|
|
|
|
certificate authority, to further verify the certificate contains the
|
2015-05-04 18:56:50 +00:00
|
|
|
proper key. More on certificates in part 2.
|
2015-05-04 18:52:26 +00:00
|
|
|
|
|
|
|
3. The client then uses the server's public key to encrypt a secret.
|
|
|
|
This secret is then sent back to the server.
|
|
|
|
|
|
|
|
4. The server decrypts the secret with it's private key. This secret
|
|
|
|
is now shared by only the client and the server, and from this point
|
|
|
|
on is used for symmetric encryption.
|
|
|
|
|
|
|
|
From this point forward, the connection is encrypted and secure from
|
|
|
|
external threats. Of course, this all depends on a trusted certificate and
|
|
|
|
proper encryption algorithms.
|
|
|
|
|
|
|
|
Step 3: Establish an HTTP connection
|
|
|
|
HTTP is an application-layer protocol, and is responsible for translating
|
|
|
|
the information from the transport layer into information used by an
|
|
|
|
application. Your web browser, for example, will utilize HTTP to translate
|
|
|
|
a bunch of hexidecimal information into alpha-numeric information, which is
|
|
|
|
then formatted and presented to you as a web page. Security is previously
|
|
|
|
established thanks to TLS/SSL, and reliability is previously established
|
|
|
|
thanks to TCP.
|
|
|
|
|
|
|
|
Of course this is an over-simplification of the whole stream. TCP itself is
|
|
|
|
worthy of many research papers. However, many sources on TCP already do an apt
|
|
|
|
job of explaining it in understandable ways. I felt that SSL was less-so
|
2015-05-04 18:56:50 +00:00
|
|
|
explained, so I wanted to dive a bit more into that. In Part 2, I'll dive more
|
|
|
|
into the TLS handshake, what certificates are and how they play a role, and the
|
|
|
|
importance of secure ciphersuites for keys.
|
2015-05-04 18:52:26 +00:00
|
|
|
|
|
|
|
|
|
|
|
============================
|
|
|
|
Sources
|
|
|
|
[1] https://en.wikipedia.org/wiki/Public-key_cryptography
|
|
|
|
[2]
|
|
|
|
https://security.stackexchange.com/questions/6290/how-is-it-possible-that-people-observing-an-https-connection-being-established-w
|
|
|
|
[3]
|
|
|
|
https://security.stackexchange.com/questions/20803/how-does-ssl-tls-work
|
2015-05-04 21:27:31 +00:00
|
|
|
|
|
|
|
============================
|
|
|
|
Notes
|
|
|
|
Asymmetric Key Authentication:
|
|
|
|
- Relies on two keys: Public key, Private key
|
|
|
|
- Both keys are related, but impossible (computationally infeasable) to
|
|
|
|
identify the private key based on the public key [1][2]
|
|
|
|
- The public key can be distributed publicly
|
|
|
|
- Used to encrypt message to the owner of the private paired key
|
|
|
|
- Used to verify signatures from the private key
|
|
|
|
- The private key is kept secret
|
|
|
|
- Used to decrypt message from the public paired key
|
|
|
|
- Used to as a digital signature
|
|
|
|
|
|
|
|
Basics of an Asymmetric Key handshake:
|
|
|
|
1. Client reaches out to server, requesting a secure connection
|
|
|
|
2. Server acknowledges request, sends back it's public key
|
|
|
|
- This is commonly known as a certificate. Often signed by a
|
|
|
|
third-party to ensure it is what it's supposed to be.
|
|
|
|
3. Client uses this public key to encrypt a secret, and sends the package
|
|
|
|
back to the server.
|
|
|
|
4. The server then uses it's private key to decrypt the public-key
|
|
|
|
encrypted secret, and uses that secret hence forth to encrypt all traffic.
|
|
|
|
5. A private connection is now established.
|
|
|
|
|
|
|
|
Basics of Certificates
|
|
|
|
1. A certificate is a vessel for a server to provide authentication
|
|
|
|
information.
|
|
|
|
2. Typically a certificate will contain the following information:
|
|
|
|
- A UUID of the certificate itself
|
|
|
|
- The subject of the certificate
|
|
|
|
- The signature, and signature algorithm used
|
|
|
|
- The issuer of the certificate, as well as dates when it is valid
|
|
|
|
- The purpose of the key
|
|
|
|
- The thumbprint, and algorithm, used to hash the key
|
|
|
|
- The public key itself
|
|
|
|
3. Certificate Authorities act as a third part to verify the integrity of
|
|
|
|
public keys.
|