New draft on TLS
This commit is contained in:
Bill Niblock
parent
4057f9eb87
commit
e9b56c9024
1 changed files with 129 additions and 0 deletions
129
_drafts/TLS_Writeup.txt
Normal file
129
_drafts/TLS_Writeup.txt
Normal file
|
|
@ -0,0 +1,129 @@
|
|||
TLS - Transport-Layer Security
|
||||
|
||||
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.
|
||||
|
||||
============================
|
||||
|
||||
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
|
||||
proper key. More on certificates below.
|
||||
|
||||
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
|
||||
explained, so I wanted to dive a bit more into that.
|
||||
|
||||
|
||||
============================
|
||||
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
|
||||
[4]
|
||||
Loading…
Reference in a new issue