Update styles; clean up drafts; begin work on TLS pt2.
This commit is contained in:
parent
7c4685c7cb
commit
b5b5808601
6 changed files with 119 additions and 152 deletions
|
@ -1,130 +0,0 @@
|
|||
TLS: An examination into the Security of the Internet, Part 1
|
||||
|
||||
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 in part 2.
|
||||
|
||||
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. 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.
|
||||
|
||||
|
||||
============================
|
||||
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
|
||||
|
||||
============================
|
||||
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.
|
88
_drafts/TLS_Writeup2.html
Normal file
88
_drafts/TLS_Writeup2.html
Normal file
|
@ -0,0 +1,88 @@
|
|||
---
|
||||
layout: default
|
||||
tabtitle: An Examination of TLS, Part 2
|
||||
title: An Examination of TLS, Part 2
|
||||
tags: tech
|
||||
---
|
||||
|
||||
<article>
|
||||
<h1>TLS: An examination into the Security of the Internet, Part 2</h1>
|
||||
|
||||
<p>TLS, more often referred to as SSL, is the means by which a secure
|
||||
connection is established over a computer network. Part 1 examines how to
|
||||
establish a secure connection using TLS. This article examines further the
|
||||
techniques and technology that makes TLS secure. Specifically, a brief
|
||||
examination of certificates, cipher suites, and public-key
|
||||
authentication.</p>
|
||||
|
||||
<h2>Certificates</h2>
|
||||
<p>A certificate is a vessel for a server to provide authentication
|
||||
information. </p>
|
||||
|
||||
<h2>Cipher Suites</h2>
|
||||
<p>A cipher is the algorithm used to encrypt the information
|
||||
to be transmitted.</p>
|
||||
|
||||
<h2>Public-Key Authentication</h2>
|
||||
<p>Big topic, very important!</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>
|
||||
|
||||
<br /><h4>[Bill Niblock][2015-05-][Technology]</h4>
|
||||
</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.
|
||||
-->
|
||||
|
||||
<!-- ================================= -->
|
||||
<!-- ================================= -->
|
|
@ -1,30 +1,31 @@
|
|||
TLS: An examination into the Security of the Internet, Part 2
|
||||
---
|
||||
layout: default
|
||||
tabtitle: An Examination of TLS, Part 2
|
||||
title: An Examination of TLS, Part 2
|
||||
tags: tech
|
||||
---
|
||||
|
||||
In Part 1, I went over how a connection is established with TLS. In this part, I
|
||||
want to examine the more involved details of TLS itself. Namely, I want to
|
||||
examine certificates, cipher suites, and public key authentication.
|
||||
<article>
|
||||
|
||||
Certificates
|
||||
<h1>TLS: An examination into the Security of the Internet, Part 2</h1>
|
||||
|
||||
|
||||
<h2>Certificates</h2>
|
||||
A certificate is a vessel for a server to provide authentication informat
|
||||
|
||||
Cipher Suites
|
||||
<h2>Cipher Suites</h2>
|
||||
A cipher is the algorithm used to encrypt the information to be transmitted.
|
||||
|
||||
Public-Key Authentication
|
||||
<h2>Public-Key Authentication</h2>
|
||||
Big topic, very important
|
||||
|
||||
|
||||
</article>
|
||||
|
||||
============================
|
||||
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
|
||||
<!-- ================================= -->
|
||||
<!-- ================================= -->
|
||||
|
||||
============================
|
||||
Notes
|
||||
<!-- 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
|
||||
|
@ -59,4 +60,8 @@ Basics of Certificates
|
|||
- 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.
|
||||
public keys.
|
||||
-->
|
||||
|
||||
<!-- ================================= -->
|
||||
<!-- ================================= -->
|
||||
|
|
|
@ -45,7 +45,7 @@
|
|||
"tour" is for; the last few games I want to play on Windows, before I go
|
||||
Linux only.</p>
|
||||
|
||||
<h2>Featuring</h2>
|
||||
<h3>Featuring</h3>
|
||||
<p>The list isn't huge, but there are some definite strong players:</p>
|
||||
<ul>
|
||||
<li>Dark Souls and Dark Souls 2</li>
|
||||
|
@ -58,7 +58,7 @@
|
|||
run fine on Windows, and they may work in Wine but I don't feel like
|
||||
either figuring out if they do, or trying to make them play nice.</p>
|
||||
|
||||
<h2>Special Guest Appearances By</h2>
|
||||
<h3>Special Guest Appearances By</h3>
|
||||
<p>There are a few games that I will fiddle with to get working in Wine
|
||||
though, and these are games I don't quite want to let go, but still are
|
||||
Windows only: Skyrim and Guild Wars 2. I love Guild Wars 2, I think it's
|
||||
|
@ -69,10 +69,12 @@
|
|||
want. Regardless, I imagine I'll be playing plenty of each of these while
|
||||
finishing up the main list.</p>
|
||||
|
||||
<h2>Tickets on Sale Now!</h2>
|
||||
<h3>Tickets on Sale Now!</h3>
|
||||
<p>Well, not exactly. But this would be a fantastic way to get into
|
||||
streaming, and maybe I'll transition from Windows to Linux with that as
|
||||
well. Streaming has always been something I've wanted to do, but never had
|
||||
the time nor effort to pursue. So, either tradition will hold strong, or a
|
||||
new challenger will appear. Until then.</p>
|
||||
|
||||
<br /><h4>[Bill Niblock][2015-04-28][Gaming]</h4>
|
||||
</article>
|
||||
|
|
|
@ -103,6 +103,8 @@
|
|||
Stack Exchange: How Does SSL/TLS work?</a></li>
|
||||
</ol>
|
||||
|
||||
<br /><h4>[Bill Niblock][2015-05-06][Technology]</h4>
|
||||
|
||||
</article>
|
||||
|
||||
<!-- ================================= -->
|
||||
|
|
|
@ -211,8 +211,8 @@ article h4 {
|
|||
text-align: center;
|
||||
padding: 10px;
|
||||
border-top: 1px solid darkgrey;
|
||||
font: 1.0em "Lucida Sans Unicode", "Lucida Grande", sans-serif;
|
||||
text-shadow: 2px 2px #DEDEDE; color: darkgrey; letter-spacing: 0.6em;
|
||||
font: 0.8em "Lucida Sans Unicode", "Lucida Grande", sans-serif;
|
||||
color: darkgrey; letter-spacing: 0.4em;
|
||||
}
|
||||
|
||||
article p {
|
||||
|
|
Loading…
Reference in a new issue