vagabond/the-internet-vagabond-dot-com
1
0
Fork 0
Code Issues 3 Pull requests Projects 2 Activity Actions

Add TLS Article

Browse source
This commit is contained in:
Bill Niblock 2015-05-06 21:12:26 -04:00
parent 3b17a5bd04
commit a17b398781
2 changed files with 153 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

1
_posts/2015-05-04-Philosophy-of-Bill,-Part-1.html
View file

@ -1,6 +1,7 @@
---
layout: default
tabtitle: Philosophy of Bill, Abbreviated
title: The Philosophy of Bill, Part 1
tags: philosophy
---

152
_posts/2015-05-06-TLS-Part-1.html Normal file
View file

@ -0,0 +1,152 @@
---
layout: default
tabtitle: TLS - Part 1
title: An Examination of TLS, Part 1
tags: tech
---
<article>
<h1>TLS: An Examination Into the Security of the Internet, Part 1</h1>
<p>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:</p>
<h2>Step 1: Establish an TCP connection</h2>
<p>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:</p>
<ol>
<li>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.</li>
<li>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.</li>
<li>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.</li>
<li>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. </li>
</ol>
<h2>Step 2: Establish an SSL/TLS Connection</h2>
<p>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:</p>
<ol>
<li>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.</li>
<li>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 in part 2.</li>
<li>The client then uses the server's public key to encrypt a secret.
This secret is then sent back to the server.</li>
<li>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.</li>
</ol>
<p>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.</p>
<h2>Step 3: Establish an HTTP connection</h2>
<p>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.</p>
<p>In Part 2, I'll dive more into the TLS handshake, what certificates are
and how they play a role. Finally, in Part 3, I'll examine the importance
of secure ciphersuites for keys, and delve a bit deeper into why public-key
authentication is so damn cool.</p>
<h3>Sources</h3>
<ol>
<li><a href="https://en.wikipedia.org/wiki/Public-key_cryptography">
Wikipedia: Public-key Cryptography</a></li>
<li><a
href="https://security.stackexchange.com/questions/6290/how-is-it-possible-that-people-observing-an-https-connection-being-established-w">Stack
Exchange: How is it possible that people observing an HTTPS
connection being established wouldn't know how to decrypt
it?</a></li>
<li><a
href="https://security.stackexchange.com/questions/20803/how-does-ssl-tls-work">
Stack Exchange: How Does SSL/TLS work?</a></li>
</ol>
</article>
<!-- ================================= -->
<!-- ================================= -->
<!-- Notes (because why remove them?)
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.
-->
<!-- ================================= -->
<!-- ================================= -->