Join for Free
Log In

artes y humanidades
Negocios
Ciencias de la Computación
Ciencia de Datos
Tecnología de información
salud
Matemáticas y Lógica
Desarrollo Personal
Ciencias Físicas e Ingeniería
Ciencias sociales
Aprendizaje de un idioma
Grados
Certificados

Explorar todo lo que Coursera tiene para ofrecer

Explorar
Buscar
For Enterprise
Inicia Sesión
Únete de forma gratuita

Putting It All Together: SSL/TLS

Loading...

Criptografía

Universidad de Maryland en College Park

4.5 (580 calificaciones) | 31K estudiantes inscritos

Curso 3 de 5 en seguridad cibernética Programa Especializado

This course will introduce you to the foundations of modern cryptography, with an eye toward practical applications.

Destrezas que aprenderás

Number Theory, Cryptography, Public-Key Cryptography

Revisiones

4.5 (580 calificaciones)

5 stars
375 ratings
4 stars
148 ratings
3 stars
36 ratings
2 stars
10 ratings
1 star
11 ratings

JD

Apr 15, 2016

Very useful insight about Cryptography, very good practical assignments. I advise it to everyone interested in Cyber Security. Very stimulating.

AM

Aug 09, 2019

Thanks to Coursera for that I have studied online this course! Also, thanks to\n\nUniversity of Maryland and to my Professor\n\nJonathan Katz.

De la lección

Week 7

Digital Signatures

Public-Key Infrastructure (PKI)14:17

Putting It All Together: SSL/TLS12:22

Parting Thoughts9:49

Impartido por:

Jonathan Katz
Professor, University of Maryland, and Director, Maryland Cybersecurity Center

Transcripción

[SOUND] In this lecture I want to

talk about the SSL/TLS protocol.

And there are really two reasons I want to do this.

The first reason is that this is an important cryptographic protocol.

It's a protocol that you use probably every day,

and it's a protocol used by millions of people around the world.

It's implemented in every browser, and

it under pins secure electronic commerce today.

And so for that reason, if you could get out of a course on cryptography without

seeing this protocol, it would be a real shame.

The second reason I want to cover this protocol,

is because it really provides a very nice way to pull together every thing we've

learned through out the entire course.

And gives you a chance to really see how these different primitives we learned

about, can operate together, and again how these things are used in the real world.

So the fundamental problem that the protocol that we're talking about here is

solving, is how can you securely send your credit card information to, for

example, Coursera?

And there are different protocol that were designed,

used under slightly different names.

SSL stands for Secure Socket Layer.

This was a protocol developed by Netscape, beginning in the mid 1990s.

And TLS stands for Transport Layer Security.

This was really an attempt to standardize the SSL protocol and

make it more widely used.

And there are several versions of this protocol that were developed.

TLS 1.0 was developed in 1999.

TLS 1.2 was standardized in 2008.

And is the current version of the TLS protocol.

And TLS 1.3 is currently in draft form.

And you can follow that and see how it continues to progress.

And as I said a moment ago, the TLS protocol is used by

every web browser when it initiates an https connection.

That is, a secure connection to a website.

Now, the goals in describing the TLS protocol to you,

are to understand at a high level.

This very important real-world crypto protocol, and

as I said at the outset, to show you how everything we've learned together,

we've learned in this course, can be pulled together.

I want to make clear that it's not my goal here,

to convey to you the low-level details of the TLS protocol.

Or exactly how the various components of TLS are implemented.

You can take out, you can look a the standard to get a sense of that.

There are books available that discuss these things in more detail.

That's not the goal of my lecture here, and so

I'm actually going to be a little bit fast and loose with details.

Because I want to convey the high level picture without getting lost in the weeds.

I also want to be clear that it is not a goal here,

to discuss what kind of security SSL/TLS is trying to achieve,

or trying to prove any kind of formal security statement for the protocol.

This is actually a current area of research in the cryptographic community.

And again it's not something I want to get bogged down in right now.

Because I really want to focus on conveying the high level picture of what

the protocol is doing.

So with those caveats in place, let's move on.

In the TLS protocol, it operates in two phases.

First, there's a handshake protocol, that allows a client and a server,

that is a user and web server that they're connecting to, to establish a shared key.

The record layer protocol, is then a second phase of the protocol which allows

those party to use the share key they just generated for secure communications.

So for example, when connecting to a web page and

initiating say, the sending of a credit card number, the handshake protocol would

be used to allow you and the web server to share a key.

And then the record layer protocol would be used to actually communicate

both the credit card information as well as details about the specific

transaction that you're performing to be

sent securely from your computer to web server at the other end.

The handshake protocol, at a high level, works in the following way.

So on the left hand side we have a client,

who you can imagine running this protocol in their web browser.

And as we discussed in the previous lecture, that client has

the public key for some certification authority stored in their browser, and

I've noted that by indicating that the client has the public key pkCA.

At the the other end on the right hand side is a merchant with whom

the user is communicating, and that merchant has a private key and

a public key pair, along with a certificate.

Find by the,

by the certification authority, again as we spoke about in the last lecture.

Certifying the binding,

between the identity of that merchant and their public key.

When the users initiates a connection by typing in an https request,

say to the websitebank.com, as part of that initial request,

the client's web browser will generate a non.

It's a random value denoted here, N sub c.

And that will be sent,

along with other information, to the bank, to the merchant at the other end.

That party will respond with a copy of their public key, their certificate, and

their own random value, their own nons, here denoted by N as well.

And now, the client first needs to verify,

that the public key that they've attained, is indeed the correct public key, right?

As we talked about in the last lecture,

you want to prevent an attacker from injecting their own public key,

their own fake pub, public key and claiming that that's

the public key of the web server with whom this client is trying to communicate.

So the client needs to verify the certificate.

Needs to verify the signature using the public key of the CA that they know.

And indeed to check whether the public key that they've received,

matches the URL, of the entity with whom they were trying to reach,

with whom they were trying to communicate.

If that verification succeeds the client now knows the copy of

the public key of the other side.

Note here that there's also an asymmetry, I guess I can go back.

There's an asymmetry here because the client does not have

a public key of their own.

And this matches our typical expectation of what happens in practice.

Right? Most of us,

probably all of us have I would venture to guess,

don't have public keys that we use in establishing TLS communication sessions.

And that's simply because in part, we don't want to manage those public keys,

and also the CAs don't want to deal with individual, end users.

They only want to work with companies and will certify in their public keys.

The protocol then continues by having the user generate a random value

called pmk, which stands for premaster key.

And encrypting that value using the public key of the web server.

That results in a cypher text fee which it sends as the third message over here.

So here we're using public key encryption to communicate a secret value from

the client to the webserver.

And I should note here,

that ideally we would like this public key encryption scheme to be CCA secure.

Because we like to protect even against an active adversary trying to

interfere with the communication.

In fact the TLS protocol does not quite use CCA encryption,

in all it's different instantiations.

But al least ideally, you can understand from our discussion,

in week six that that's what you would like to use here.

The client can,

at the same time it's doing this, use a key derivation function, KDF.

To derive MK, a master key, from the PMK and the nonces from both sides.

It can then apply a sutorandom generator G,

to the master key to derive four different keys.

On the other end after receiving the cipher text the web server can decrypt and

recover PMK and than apply the same procedure as the client did.

Namely apply the key derivation function to obtain mk,

and then apply a single random generator to mk

to expand that short secret value to a set of four different keys.

The client then computes a message of authentication code

over the entire transcript of the communication thus far.

And it computes that message authentication code using the secret

value, mk, that its computed, and

then hopefully the other side has computed as well.

The web server can then verify this message authentication code.

Check that not only is the tag correct, but that the tag is

correct on its own view of the transcript of the protocol up to that point.

The idea here is to make sure that any message sent by the client, by the user,

was received unmodified by the web server and vice versa.

And then if so, the web server will do the same thing in reverse.

It will compute its own message authentication code,

using mk on the transcript, up to that point in the protocol.

And note it that the transcript is slightly different here because there's

been an extra message in between when the client sent its own MAC, and

when the server responded with its own.

And for those of you who are particular here, I will point out that this is not

exactly how the handshake protocol works, but this ist he core idea of how

the handshake, with the final two messages of a handshake protocol work.

The client of course has to verify that tag as well so that it can check that no

messages were modified in it's interaction with the web server either.

Now after a successful completion of the handshake protocol.

The thing to note is that the user and the webserver now share four different keys.

And it's those keys that they can then use in the record layer

protocol to secure their communications.

So again the parties now share these four keys kc, kc prime, ks, and ks prime.

And the client is going to use kc and

kc prime to encrypt and authenticate all the messages it sends.

If you remember back to one of the earlier weeks in

this course you remember we talked about the notion of authenticated encryption.

And said that one way to achieve authenticated encryption is the encrypt,

then authenticate approach, using independent keys and

you can see here that TLS exactly provides independent keys for

encryption and authentication to the client.

Analogously, the server will use KS and KS prime to encrypt and

authenticate all the messages that it sends.

And if you remember back to our discussion of secure communication sessions,

we mentioned there that one potential issue is a reflection attack.

Where a client sends a message and then an attacker re-directs that back at

the client and the client verifies and everything seems okay.

there, we found that we addressed that issue by incorporating identities

into what was authenticated.

Here that problem is being addressed by having the client and

server use different keys.

So the reflection attack would not work in that case.

Now, we also talked in our discussion of secure communications sessions about

the need to prevent replay attacks to prevent the message as being replayed and

being accepted as valid.

By the other side, I'll mention that sequence numbers, kind of like the counter

base solution we talked about then, are used here to prevent such replay attacks.

And that concludes our discussion of the protocol.

Now you know about how a real world protocol you use everyday, actually works.

Explora nuestro catálogo

Inscríbete de manera gratuita y obtén recomendaciones personalizadas, actualizaciones y ofertas.

Coursera brinda acceso universal a la mejor educación del mundo, al asociarse con las mejores universidades y organizaciones, para ofrecer cursos en línea.

© 2019 Coursera Inc. Todos los derechos reservados.

Descargar en la App Store

Consíguelo en Google Play

Coursera
Acerca de
Liderazgo
Empleo
Catálogo
Certificados
Certificados MasterTrack™
Grados
For Enterprise
For Government

Comunidad
Learners
Partners
Developers
Beta Testers
Translators

Conectar
Blog
Facebook
LinkedIn
Twitter
Instagram
Youtube
Blog de Tecnología

Más
Términos
Privacidad
Ayuda
Accesibilidad
Prensa
Contacto
Directorio
Afiliados