Add an Understanding TLS chapter #4

mattcaswell · 2017-12-13T17:51:39Z

Stills needs some content on sessions and resumption

InfoHunter · 2018-01-25T08:22:43Z

tls/understand-tls/understand-tls.tex

+Force or IETF, is an organisation that publishes many of the standards relevant 
+to SSL/TLS. The standards are published in the form of documents known as RFCs. 
+The most significant of these from our perspective are RFC6101 (SSL3.0), 
+RFC2246 (TLS1.0), RFC4346 (TLS1.1) and RFC5246 (TLS1.2)} and was renamed to TLS 


Seems TLS1.3 could be added here.

And for a starter, he/she might feel confused about why SSL3.0 RFC number is greater than all TLS RFC numbers, would it be better if a footnote is added here to explain the RFC6101 is a 'historical record'?

Ok, I added it as RFCXXXX. It'll need to be filled in when its published.

This text is actually already in a footnote...so a footnote to a footnote seems to be going a bit far? ;-)

Ahh, didn't notice it's in footnote...

InfoHunter · 2018-01-25T08:39:30Z

tls/understand-tls/understand-tls.tex

+Identity is established through the use of a \emph{digital certificate}. The 
+digital certificate provides public data about a server for which it is issued. 
+For example, the certificate will contain the hostname(s) for which it is 
+valid. In order to obtain a certificate a server operator must first create a 


Since the CA is going to be talked about in following paragraph, I guess this sentence could be adjust a little. Because nowadays it's common for server operators get their [private key + certificate] together from the CA via some cloud computing platforms, with one-button-click...

So readers might be confused about: why I don't need to prepare a pair of pub/priv keys and I can still get them from a certificate seller? :-)

Because nowadays it's common for server operators get their [private key + certificate] together from the CA via some cloud computing platforms, with one-button-click...

I did not know that. Interesting. I added this sentence a little further down:

"Some cloud computing platforms provide the capability to generate a private key
and a CA issued certificate in a single operation as part of the cloud service."

Does that cover it?

Yes, I think this is fine.

InfoHunter · 2018-01-25T08:58:21Z

tls/understand-tls/understand-tls.tex

+Both the digital certificate, and the associated private key are installed on 
+the SSL/TLS server. When a client accesses the server, the server will send 
+its certificate back to the client. In order for authentication to be
+successful the client must verify two things:


Seems there should be the 3rd thing to verify: the identity the server declaims is matched with the certificate, specifically the CN field?

E.g., Alice wants to connect to aaa.com, and Eve hijacks the traffic to bbb.com which domain is owned by Eve so she can have the valid bbb.com certificates and corresponding private key, if Alice doesn't check the CN of the certificate she gets, tragedy happens....

Good point. I added that.

InfoHunter · 2018-01-25T09:00:01Z

tls/understand-tls/understand-tls.tex

+As mentioned above it is also possible for the server to authenticate the 
+client as part of the SSL/TLS protocol. If this capability is used then it works
+in a very similar way  to that described above. The primary difference is that
+the client will also have to create a private/public key pair and obtain a


I guess this could also need to consider the scenario without key generation by users. Same as above discussion.

Hmmm...maybe...but this seems less likely to be automated by a cloud provider? If someone is planning on setting up a client auth infrastructure then they're going to need to have a really good understanding on what is really happening.

InfoHunter · 2018-01-25T09:04:05Z

tls/understand-tls/understand-tls.tex

+length input data and output a fixed length ``hash'' value that exhibits 
+certain security properties (including that it is not possible to derive the 
+input data from the hash output). Alternatively, integrity could be provided by
+a \emph{mode} of the underlying  encryption cipher. Modes are a complex topic,


Should mode be notified in the 'Encryption' section above? 'Modes' sounds more like to use defined due to symmetric ciphers....

Right - but in the context of SSL/TLS, we're only really interested in whether the mode provides integrity or not. So in my mind it seems to sit better here.

Okay, that's also rational.

mattcaswell · 2018-01-25T15:19:52Z

I made some updates to take account of TLSv1.3 in a few places. Also various updates for @InfoHunter's comments.

levitte · 2018-01-29T03:00:56Z

Makefile

@@ -11,7 +11,8 @@ EXE=

 BOOKELEMS= openssl-book.tex

-all: openssl-book.pdf
+all: openssl-book.pdf \
+	tls/understand-tls/understand-tls.tex


Hmm? Shouldn't it rather be added in BOOKELEMS above? And foundations/about/about.tex should as well, yeah?

Oh, yeah. You're right - good catch. Fixed.

mattcaswell · 2018-01-30T12:17:13Z

I added some new content on sessions and key updates. Taking this out of WIP. Please review!

InfoHunter · 2018-01-30T15:28:18Z

tls/understand-tls/understand-tls.tex

+to perform a \emph{renegotiation}. This is a new handshake on an already
+existing connection. The new handshake can be full, or it could be abbreviated
+using previously saved session information (such as from the original
+handshake). A renegotiation handshake is not allowed in TLS 1.3.


I am not sure if it's necessary to mention a bit here that the renegotiation is not secure and thus in TLS 1.3 it's obsolete by the new mechanism.

And also, this paragraph, it sounds like the renegotiation is only the alternative for key update, but it seems renegotiation has other usages like force-a-client-authentication...

I added some more text at the end to cover this.

Mention previous security issues with reneg, and also its use to force client authentication.

mattcaswell · 2018-01-31T15:28:23Z

Ping @openssl/committers for review.

nickthetait · 2018-02-01T05:42:16Z

tls/understand-tls/understand-tls.tex

+to SSL/TLS. The standards are published in the form of documents known as RFCs. 
+The most significant of these from our perspective are RFC6101 (SSL3.0), 
+RFC2246 (TLS1.0), RFC4346 (TLS1.1), RFC5246 (TLS1.2) and RFCXXX (TLS1.3)} and
+was renamed to TLS (Transport Layer Security).


nickthetait · 2018-02-01T06:11:43Z

tls/understand-tls/understand-tls.tex

+is shown in figure \ref{fig:typical-hand}.
+
+\begin{figure}[t]
+\fbox{\includegraphics[width=0.9\textwidth]{tls/understand-tls/typicalhand.pdf}}


Think this graphic needs a indicator for time. Like an arrow on the right side which points downwards?

This depicts an initial connection of TLS, not an entire session right?

I added a time indicator.

This depicts an initial connection of TLS, not an entire session right?

Correct (this whole section describes the initial handshake, as explained in the text)

nickthetait · 2018-02-01T06:13:46Z

tls/understand-tls/understand-tls.tex

+is shown in figure \ref{fig:typical-hand}.
+
+\begin{figure}[t]
+\fbox{\includegraphics[width=0.9\textwidth]{tls/understand-tls/typicalhand.pdf}}


This depicts an initial connection of TLS, not an entire session right?

nickthetait · 2018-02-01T06:15:25Z

tls/understand-tls/understand-tls.tex

+
+A typical ClientHello contains:
+\begin{itemize}
+\item The highest protocol version supported by the client or, for TLS 1.3, a


Would be helpful if these bullet points were numbered. Then the graphic could be labeled and described better.

Disagree. This bullet point list describes just the initial ClientHello. As such they all apply to the very first arrow on the diagram - so I don't think it would be helpful to add additional labels to the diagram.

nickthetait · 2018-02-01T06:18:12Z

tls/understand-tls/understand-tls.tex

+using previously saved session information (such as from the original
+handshake).
+
+There have been historic security issues with renegotiation, and for that


Worth linking to an example of the research/data for one of these?

I added a footnote with a reference

Also, makes a few other tweaks based on feedback received.

FdaSilvaYY

just some typo

FdaSilvaYY · 2018-02-11T22:08:35Z

tls/understand-tls/understand-tls.tex

+application data is sent until the connection has been established and
+cryptographic parameters have been agreed. A MAC of the entire set of handshake 
+messages is calculated and verified at the last step of the handshake process. 
+In this way, even though inidividual records do not have integrity protection, 


inidividual

FdaSilvaYY · 2018-02-11T22:08:45Z

tls/understand-tls/understand-tls.tex

+
+The initial exchange of messages during which cryptographic parameters are 
+exchanged is known as the \emph{handshake}. While making the initial connection
+no crypotgraphic parameters will have yet been agreed. Therefore there is no


crypotgraphic

FdaSilvaYY · 2018-02-11T22:09:46Z

tls/understand-tls/understand-tls.tex

+Having obtained a private/public key pair a server operator must obtain their
+certificate from a \emph{Certificate Authority} (CA)\footnote{CAs can be
+privately run and purely internal to an organisation; or they could be public.
+Which type is most appropriate will depend on what the certificte will be used


FdaSilvaYY · 2018-02-11T22:09:53Z

tls/understand-tls/understand-tls.tex

+A group of algorithms combined in this way is known as a \emph{ciphersuite}. 
+There are many different ciphersuites that are available\footnote{At the time 
+of writing OpenSSL 1.1.0 supports 168 different ciphersuites}. Each
+ciphersuite identifies a set of algorithms that it will use to satsify the 


FdaSilvaYY · 2018-02-11T22:10:37Z

tls/understand-tls/understand-tls.tex

+between both ends of the communication and must be \emph{private} to prevent an
+eavesdropper from being able to decrypt messages. Key exchange algorithms solve 
+the problem of how two parties will agree on a key without enabling an 
+eavedropper to work out what it is. Examples of algorithms that are used for 


s/eavedropper/eavesdropper

FdaSilvaYY · 2018-02-11T22:11:02Z

tls/understand-tls/understand-tls.tex

+information:
+\begin{itemize}
+\item The ciphersuite name such as \lstinline!ECDHE-ECDSA-AES256-CCM8!.
+\item The earliest protcol version that the ciphersuite is available from. Note 


FdaSilvaYY · 2018-02-11T22:15:59Z

tls/understand-tls/understand-tls.tex

+In this way, even though inidividual records do not have integrity protection, 
+the handshake as a whole does.
+
+Handshake messages are transmitted between the client and server in rec-ords. A 


mattcaswell added 2 commits December 13, 2017 17:50

Add an Understanding TLS chapter

119527a

Make some updates for TLS 1.3

8de3175

InfoHunter reviewed Jan 25, 2018

View reviewed changes

Some tweaks based on review feedback from Paul Yang

b85d259

levitte reviewed Jan 29, 2018

View reviewed changes

mattcaswell added 2 commits January 29, 2018 10:29

Fix a Makefile bug

1427599

Add some content on sessions and key updates

76bc156

mattcaswell changed the title ~~WIP: Add an Understanding TLS chapter~~ Add an Understanding TLS chapter Jan 30, 2018

InfoHunter reviewed Jan 30, 2018

View reviewed changes

Add some text about renegotiation

8d4eb9e

Mention previous security issues with reneg, and also its use to force client authentication.

nickthetait reviewed Feb 1, 2018

View reviewed changes

Add a time indicator to the handshake graphic

ce37d01

Also, makes a few other tweaks based on feedback received.

FdaSilvaYY reviewed Feb 11, 2018

View reviewed changes

Add an Understanding TLS chapter #4

Are you sure you want to change the base?

Add an Understanding TLS chapter #4

Conversation

mattcaswell commented Dec 13, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mattcaswell commented Jan 25, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mattcaswell commented Jan 30, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mattcaswell commented Jan 31, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

FdaSilvaYY left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment