The following content is
provided under a Creative Commons license. Your support will help
MIT OpenCourseWare continue to offer high quality
educational resources for free. To make a donation, or to
view additional materials from hundreds of MIT courses,
visit MIT OpenCourseWare at ocw.mit.edu. PROFESSOR: Now look
at how the web uses cryptographic protocols to
protect network communication and deal with network
factors in general. So before we dive
into the details, I want to remind you
there's a quiz on Wednesday. And that's not in this room. It's in Walker. But it's at the
regular lecture time. Any questions about that? Hopefully straightforward. Third floor, I
think it is usually. All right. So today we're going to talk
about how the web sort of uses cryptography to protect
network communication. And we'll look at two sort
of closely related topics. One is, how do you just
cryptographically protect never communication in a larger
scale than the Kerberos system we looked at in last lecture? And then also, we're going to
look at how do you actually integrate this cryptographic
protection provided to you at the network level into
the entire application. So how does the web
browser make sense of whatever guarantees the
cryptographic protocol is providing to it? And these are closely
related, and it turns out that protecting network
communications is rather easy. Cryptography mostly just works. And integrating it in,
and currently using it at a higher level
in the browser, is actually that
much trickier part, how to actually build a
system around cryptography. Before we dive into
this whole discussion, I want to remind
you of the kinds of cryptographic primitives
we're going to use here. So in last lecture on
Kerberos, we basically used something called
symmetric crypto, or encryption and decryption. And the plan there is that
you have a secret key k, and you have two functions. So you can take
some piece of data, let's call it p for
plain text, and you can apply an encryption
function, that's a function of some key k. And if you encrypt this plain
text, you get a Cypher text c. And similarly, there's a
description function called d, that given the same key k. And the cipher text will give
you back your plain text. So this is the primitive that
Kerberos was all built around. But it turns out there's
other primitives, as well, that will be useful
for today's discussion. And this is called asymmetric
encryption and decryption. And here the idea is to have
different keys for encryption and decryption. We'll see why this is so useful. And in particular, the
functions that you get is, you can encrypt to
a particular public key with a sum message and
get a cipher text text. And in order to
decrypt, you just supply the corresponding secret
key to get the plain text back. And the cool thing now as you
can publish this public key anywhere on the
internet, and people can encrypt messages for you,
but you need the secret key in order to decrypt
the messages. And we'll see how this
is used in the protocol. And in practice you'll
often use public key crypto in a slightly different way. So instead of encrypting
and decrypting messages, you might actually want to
sign or verify messages. Turns out that at the
implementation level these are related operations,
but at an API level they might look all
little bit different. So you might find a message
with your secret key, and you get some sort
of a signature s. And then you can also
verify this message using the corresponding public key. And you get the message, and
the signature, and outcomes, and some Boolean flags
saying whether this is the correct signature
not on that message. And there are some relatively
intuitive guarantees that these functions provide
if you, for example, got this signature and it
verifies correctly, then it must have been
generated by someone with the correct secret key. Make sense, in terms of
the primitives we have? All right. So now let's actually
try to figure out-- How would we protect
network communication at a larger scale in Kerberos. In Kerberos, we had
the fairly simple model where we had all the
users and servers have some sort of a relation
with this KDC entity. And this KDC entity
has this giant table of principles and their keys. And whenever a user wants
to talk to some server, they have to ask the KDC
to generate a ticket based on those giant
table the KDC has. So this seems like a reasonably
straightforward model. So why do we need
something more? Why is Kerberos not
enough for the web? Why doesn't the web use
just Kerberos for securing all communications? AUDIENCE: [INAUDIBLE] PROFESSOR: Yeah. So there a sort of a single
KDC, has to be trusted by all. So this is, perhaps, not great. So you might have
trouble really believing that some machine out there
is secure for everyone in the world to use. Like, yeah, maybe
people at MIT are willing to trust
someone at [? ISNT ?] to run the KDC there. All right. So that's plausible, yeah. AUDIENCE: [INAUDIBLE] PROFESSOR: Yes. A key management is
hard, I guess, yeah. So what I mean in particular
by key management-- AUDIENCE: [INAUDIBLE] PROFESSOR: Yes. It might actually be a hard
job to build a KDC that we can manage a billion keys,
or ten billion keys, for all the people in the world. So it might be a
tricky proposition. If that's not the
case, then I guess another bummer with Kerberos
is that all users actually have to have a key, or have
to be known to the KDC. So, you can't even
use Kerberos at MIT to connect to some servers,
unless you yourself have an account in
the Kerberos database. Whereas on the web, it's
completely reasonable to expect the you walk
up to some computer, the computer has no
idea who you are, but you can still go to
Amazon's website protected with cryptography. Yeah? AUDIENCE: [INAUDIBLE] PROFESSOR: That's our idea. So there's these kinds
of considerations. So there's private
forward secrecies. There are a couple
of other things you want from the
cryptographic protocol, and we'll look at them and
how they sort of show up in SSL, as well. But the key there is that
the solution is actually exactly the same as what
you would do Kerberos, and what you would do in SSL
or TLS to address those guys. But you're absolutely right. There Kerberos deep
protocols we read about in the paper is pretty dated. So, even if you were
using it for the web, you would want to apply
some changes to it. Those are not huge though,
at the [INAUDIBLE] level. Any other thoughts on why
we should use Kerberos? Yeah? AUDIENCE: [INAUDIBLE] PROFESSOR: This is
actually not so scalable. Yeah, recovery. Maybe registration
even, as well, like you have to go to
some accounts office and get an account. Yeah? AUDIENCE: [INAUDIBLE]
needs to be online. PROFESSOR: Yeah, so
that's another problem. These are sort of
management issues, but at the protocol
level, the KDC has to be online
because it has actually mediate every interaction
you have with the service. It means that in the web, every
time you go to a new website, you'd have to talk to
some KDC first, which would be a bit of a
performance bottleneck. So like another
kind of scalability, this is like
performance scalability. This is more management
scalability kind of stuff. Make sense? So, how can we
solve this problem with these better primitives? Well, the idea is to use
public key cryptography to give this KDC out of the loop. So let's first
figure out whether we can establish secure
communication if you just know some other party's public key. And then we'll
see how we plug-in a public key version of a
KDC to authenticate parties in this protocol. If you don't want
to use a KDC, what you could do with
public key crypto is maybe you can somehow
learn the public key of the public key of the
other value on a connector. So in Kerberos, if I want
to connect to a file server, maybe I just know the
file server's public key from somewhere. Like me as a freshman I get
a printout saying the file server's public key is this. And then you can go
ahead and connect it. And the way you might
actually do this is you could just encrypt a message
for the public key of the file server that you
want to connect to. But it turns out
that in practice, these public key
operations are pretty slow. They are several
orders of magnitude slower than symmetric
key cryptography. So almost always you want to get
out of the use of public crypto as soon as practical. So a typical protocol
might look like this where you have a and b, and
they want to communicate. And a knows b's public key. So what might happen is
that a might generate some sort of session s. Just pick a random number. And then it's going to send
to b the session key s. So this is kind of
looking like Kerberos. And we're going to encrypt
the session s for b's key. And remember in Kerberos,
in order to do this, we have to have the
KDC do this for us because a didn't
know the key for b, or couldn't have been allowed to
know because that is a secret. But only b should've known. With public key cyrptor
you can actually this now. We can just encrypt the secret
s using these public keys. And we send this
message over to b. B can now decrypt this
message, and say I should be using this secret key. And now we can have a
communication channel where all the messages
are just encrypted under this secret key s. Does this Make sense? So there are some nice
properties about this protocol. One is that we got
rid of having to have a KDC be online and generate
our session key for us. We could just have
one of the parties generate it and then
encrypt it for another party without the use of the KDC. Another nice thing
is we're probably pretty confident that
messages sent by a to b will only be read by b. Because only b could have
decrypted this message. And therefore,
only b should have that corresponding secret key s. But this is pretty nicely. Any questions about
this protocol? Yeah? AUDIENCE: Does it matter
whether the user or the server generates the pass code? PROFESSOR: Well, maybe. I think it depends on
exactly the considerations, or the properties you
want out of this protocol. So here, certainly if a is
buggy or picks bad randomness, the server then sends some
data back to a, thinking, oh, this is now the only data
that is going to be seen by a. Well, maybe that's not
going to be quite right. So you might care a little bit. There's a couple of other
problems with this protocol, as well. Question? AUDIENCE: I was gonna say
that in this protocol, a you could just do [INAUDIBLE]. PROFESSOR: Yes, that's
actually not great. So there's actually
several problems with this. One is the replay. So the problem here
is that I can just send these messages
again, and it looks like a is sending these
messages to b, and so on. So typically the
solution to this is to have both
parties participate in the generation of
s, and that ensures that the key we're
using is now fresh. Because here, because b didn't
actually generating anything, these protocol messages look
exactly the same every time. So typically, what happens
is that, one party picks a random number like s, and
then another party b also picks some random number,
typically called a non. But, whatever. There's two numbers. And then the key they
agreed to use in the thing that one party picked,
but actually is the hash of the things
that both of them picked. So you could do that. You could also do
[? DP Helmond ?] kind of stuff like we looked at
in the last lecture where you get forward secrecy. It was a little bit more
complicated math rather than just hashing two random numbers
that two parties picked. But then you get
some nice properties, like forward secrecy. So replay attacks
you typically fixed by having b generate some nons. And then you set
the real secret key that you're going to use
to hash of the secret key from one guy concatenated
with this non. And, of course, b would
have to send the nons back to a in order to
figure out what's going on for both of
them to agree on a key. All right. So another problem here is that
there's no real authentication of a here, all right? So a knows who b
is, or at least a knows who will be able
to decrypt the data. But b has no idea who
is on the other side, whether it's a or some adversary
impersonating a, et cetera. So how would we fix it
int his public key world? Yeah? AUDIENCE: You have been assigned
something and [INAUDIBLE]. PROFESSOR: Yeah. There's a couple of ways
you could go about this. One possibility
is a maybe should sign this message
initially, because we have this nice sign primitive. So we could maybe have a sign
this thing with a's secret key. And that sign just
provides the signature, but presumably you
assign it and also provide the message, as well. And then b would have to
know a is public key in order to verify the signature. But if b knows a is
public key, then b's going to be reasonably
confident that a is the one that sent this message over. Make sense? Another thing you could
do is rely on encryption. So maybe b could send the
nons back to a encrypted under a's public key. And then only a would be
able to decrypt the nons and generate the final
session key s prime. So there are a couple
of tricks you could do. This is roughly how
client certificates work in web browsers today. So a has a secret
key, so when get an MIT personal certificate,
what happens is your browser generates a long
lived secret key and gets a certificate for it. And whenever you send
to request a web server, you're going to prove
the fact that you know the secret key in
your user certificate, and then establish the
secret key s for the rest the communication. Make Sense? All right. These are sort of all fixable
problems at the protocol level that are reasonably
easy to V address by adding extra messages. The big assumption here, of
course, that we're going under is that all the parties know
each other's public keys. So do you actually discover
someone's public key? for, you know, it a wants
to connect a website, I have a URL that I want to
connect to, or a host name, how do I know what pub
key that corresponds to? Or similarly, if I connect to
websis to look at my grades, how does the server know
what my public key should be, as opposed to the public key
of some other at person MIT? So this is the main problem
that the KDC was addressing. I guess the KDC was solving
two problems for us before. One it that is was
generating this message. It was generating
the session key and encrypting it
for the server. We fixed that by doing
public key crypto now. But we also need to get this
mapping from string principal names to cryptographic keys
of the Kerberos previously provided to us. And the way that
is going to happen in this the https world,
this protocol called TLC, is that we're going to
still rely on some parties to maintain, of to
a least logically maintain those giant tables
mapping principal names onto cryptographic keys. And the plan is, we're
going to have something called a certificate authority. This is often abbreviated
as CA in all kinds of security literature. This thing is also going
to logically maintain the stable of, here's
the name of a principle, and here's the public
key for that principle. And the main difference from
the way Kerberos worked, is that this
certificate authority thing isn't going to have to
be online for all transactions. So in Kerberos you have
to talk to those KDCs to get a connection or
to look up someone's key. Instead, what's going to
happen in this CA world, is that if you have some
name here, and a public key, the certificate
authority is going to just sign messages stating
that certain rows exist in this table. So the certificate
authority is going to have its own sort of
secret and public key here. And it's going to
use the secret key to find messages for other
users in the system to rely on. So if you have a
particular entry like this, in this CA's
database, then the CA is going to find a
message saying this name corresponds to this public key. And it's going to sign
this whole message with CA's secret key. Make sense? So this is going to allow us to
do very similar things to what Kerberos was doing,
but we are now going to get rid of
the CA having to be online for all transactions. And in fact, it's now going
to be much more scalable. So this is what's usually
called a certificate. And the reason this is going
to be much more scalable is that, in fact, to a client,
or anyone using this system, a certificate provided
from one source is as good as a certificate
provided from any other source. It's signed by
the CA secret key. So you can verify its
validity without having to actually contact
the certificate authority, or any other
designated party here. And typically, the way
this works is that a server that you want to talk to
stores the certificate that it originally got from the
certificate authority. And whenever you connect
to it, the server will tell you, well,
here's my certificate. It was signed by this CA. You can check the
signature and just verify that this is, in fact, my
public key and that's my name. And on the flip
side, the same thing happens on client certificates. So when you the user connect to
a web server, what's actually going on is that your
client certificate actually talks about the public key
corresponding to the secret key that you originally
generated in your browser. And this way when you
connect to a server, you're going to present
a certificate signed by MIT's certificate authority
saying your user name corresponds to this public key. And this is how the server
is going to be convinced that a message signed
with your secret key is proof that this is the right
Athena user connecting to me. Does that make sense? Yeah. AUDIENCE: Where does
the [? project ?] get the certificate [INAUDIBLE]? PROFESSOR: Ah, yes. Like the chicken
and the egg problem. It keeps going down. Where do you get
these public keys? At some point you have
to hard code these in, or that's typically
what most systems do. So today what
actually happens is that when you download
a web browser, or you get a computer
for the first time, it actually comes with
public keys of hundreds of these certificate
authorities. And there's many of them. Some are run by security
companies like VeriSign. The US Postal Service has
a certificate authority, for some reason. There's many entities there
that could, in principal, issue these certificates and are
fully trusted by the system. These mini certificate
authorities are now replacing the trust
that we had in this KDC. And sometimes, we
haven't actually addressed all the problems
we listed with Kerberos. So previously were worried
that, oh man, how are we going to trust? How is everyone
in the word going to trust a single KDC machine? But now, it's actually worse. This is actually worse that
in some ways, because instead of trusting a
single KDC machine, everyone is now trusting
these hundreds or certificate authorities because all of
them are equally as powerful. Any of them could sign
a message like this and it would be
accepted by clients as a correct statement
saying this principle has this public key. So you have to only break
into one of these guys instead of the one KDSC. Yeah? AUDIENCE: Is there a
mechanism to open the keys? PROFESSOR: Yeah. That's another hard problem. It turns out to be that
before we talked to the KDC, and if you screwed
up, you could tell the KDC to stop giving
out my key, or change it. Now the certificates are
actually potentially valid forever. So the typical
solution is twofold. One is, sort of expectedly,
these certificates include an expiration time. So this way you can at
least bound the damage. Is This is kind of like a
Kerberos ticket's lifetime, except in practice, these
tend to be to several orders of magnitude higher. So in Kerberos, your
ticket's lifetime could be a couple hours. Here it's typically a year
or something like this. So the CAs really don't want
to be talked to very often. So you want to get
your money once a year for the
certificate, and then give you out this
blob of signed bytes, and you're good
to go for a year. You don't have to
conduct them again. So this is good for scalability,
but not so good for security. And there's two problems
that you might worry about with certificates. One is that Maybe
the CA's screwed up. So maybe the CA issued a
certificate for the wrong name. Like, they weren't very careful. And accidentally, I
ask them to give you a certificate for amazon.com,
and they just slipped up and said, all right, sure. That's amazon.com. I will give you a
certificate for that. So that seems like a
problem on the CA side. So they miss-issued
a certificate. And that's one way that you
could end up with a certificate that you wish no longer
existed, because you signed the wrong thing. Another possibility
is that they CA does the right thing,
but then the person who had the certificate I
accidentally disclosed the secret key, or someone stole
the secret key corresponding to the public key
in the certificate. So this means that
certificate no longer says what you think it might mean. Even though this says
amazon.com's key is this, actually every one
in the world has the corresponding secret
key because posted it on the internet. So you can't really
learn much from someone sending you a message signed by
the corresponding secret key, because it could've been anyone
that stole the secret key. So that's another
reason why you might want to revoke a certificate. And revoking certificates
is pretty messy. There's not really
a great plan for it. The two alternatives
that people have tried are to basically publish
a list of all revoked certificates in the world. This Is something called
certificate revocation list, or CRLs. And the way this works
is that every certificate authority issues
these certificates, but then on the side, it
maintains a list of mistakes. These are things
that it realized they screwed up and
issued a certificate under the wrong name, or
our customers come to them and say, hey, you
issued me a certificate. Everything was going great. But someone then got
rude on my machine and stole the private key. Please tell the world that my
certificate is no good anymore. So this certificate
authority, in principle, could add stuff to this CRL, and
then clients like web browsers are supposed to download
this CRL periodically. And then whenever they're
presented with a certificate, they should check
if the certificate appears in this revoked list. And it shows up
there, then should say that certificate's no good. You better give me a new one. I'm not going to trust
this particular sign message anymore. So that's one plan. It's not great. If you really used, it
would be a giant list. And it would be quite a lot
of overhead for everyone in the world to download this. The other problem is
that no one actually bothers doing this stuff. so
the lists in practice are empty. If you actually ask all
these CAs, most of them will give you back an empty CRL
because no one's ever bothered to add anything to this list. Because, why would you? It will only break
things because it will reduce the number of
connections that will succeed. So it's not clear whether there
is a great motivations for CAs to maintain this CRL. The other thing that
people have tried is to query online the CAs. Like in the Kerberos world, we
contact the KDC all the time. And in the CA world we try
to get out of this business and say, well, the
CA's only going to sign these
messages once a year. That's sort of a bummer. So there's an
alternative protocol called online certificate
status protocol, or OCSP. And this protocol pushes
us back from the CA world to the KDC world. So whenever a client
gets a certificate and they're curious, is this
really a valid certificate? Even though it's before
the expiration time, maybe something went wrong. So using this OCSP protocol,
you can contact some server and just say, hey, I
got this certificate. Do you think it's still valid? So basically, offloading the
job of maintaining this CRL to a particular server. So instead of downloading
a whole list yourself, you're going to ask
the server, hey, is this thing in that list? So that's another plan
that people have tried. It's also not used very
widely because of two factors. One is that it adds latency to
every request that you make. So every time you want
to connect to a server, now you have to first
connect, get the certificate from the server. Now you have to talk
to this OCSP guy and then wait for him to respond
and then do something else. So for latency reasons,
this is actually not a super popular plan. Another problem
is that you don't want this OCSP thing being down
from affecting your ability to browse the web. Suppose this OSCP
server goes down. You could, like, disable
the whole internet because you can't check
anyone's certificate. Like, it could be all bad. And then all your
connections stop working. So no one wants that. So most clients
treat the OCSP server being down as sort
of an OK occurrence. This is really bad from
a security perspective because if you're
an attacker and you want to convince
someone that you have a legitimate certificate, but
it's actually been revoked, all you have to do
is somehow prevent that client from talking
to the OCSP server. And then the client will say,
well, I do the certificate. I'll try to check
it, but this guy doesn't seem to be around,
so I'll just go for it. So that's basically the
sort of lay of the land as far as verification goes. So there's no real great answer. The thing that
people do in practice as an alternative to this
is that clients just hard code in really bad mistakes. So for example, the Chrome
web browser actually ships inside of it with
a list of certificates that Google really
wants to revoke. So if someone
mis-issues a certificate for Gmail or for some other
important site-- like Facebook, Amazon, or whatever-- then
the next release of Chrome will contain that thing in
its verification list baked into Chrome. So this way, you don't have
to contact the CRL server. You don't have to
talk to this OCSP guy. It's just baked in. Like, this certificate
is no longer valid. The client rejects it. Yeah. AUDIENCE: Sorry, one last thing. PROFESSOR: Yeah. AUDIENCE: So let's say
I've stolen the secret key on the certificate [INAUDIBLE]. All public keys are
[? hard coded-- ?] PROFESSOR: Oh, yeah. That's [INAUDIBLE] really bad. I don't think there's any
solution baked into the system right now for this. There have been
certainly situations where certificate
authorities appear to have been compromised. So in 2011, there
were two CAs that were compromised in the
issue, or they were somehow tricked into issuing
certificates for Gmail, for Facebook, et cetera. And it's not clear. Maybe someone did
steal their secret key. So what happened is I
think those CAs actually got removed from a
set of trusted CAs by browsers from that point on. So the next release of Chrome
is just like, hey, you're really screwed up. We're going to kick you
out of the sort of CAs that are trusted. And it was actually
kind of a bummer because all of the
legitimate people that had certificates from
that certificate authority are now out of luck. They have to get
new certificates. So this is a somewhat
messy system, but that's sort of what happens
in practice with certificates. Make sense? Other questions
about how this works? All right. So this is the sort of general
plan for how certificates work. And as we were
talking about, they're sort of better than
Kerberos in the sense that you don't have to
have this guy be online. It might be a little
bit more scalable because you can
have multiple KDCs, and you don't have
to talk to them. Another cool thing
about this protocol is that unlike Kerberos,
you're not forced to authenticate both parties. So you could totally
connect to a web server without having a
certificate for yourself. This happens all the time. If you just go to
amazon.com, you are going to check that
Amazon is the right entity, but Amazon has no idea who you
are necessarily, or at least not until you log in later. So the crypto protocol level,
you have no certificate. Amazon has a certificate. So that was actually
much better than Kerberos where in order to connect
to a Kerberos service, you have to be an entry in
the Kerberos database already. One thing that's a little bit
of a bummer with this protocol as we've described it is
that in fact, the server does have to have a certificate. So you can't just
connect to a server and say, hey, let's
just encrypt our stuff. I have no idea who you
are, or not really, and you don't have
any idea who I am, but let's encrypt it anyway. So this is called
opportunistic encryption, and it's of course vulnerable
to man in the middle attacks because you're connecting
to someone and saying, well, let's encrypt
our stuff, but you have no idea who it really is
that you're encrypting stuff with. Both might be a
good idea anyway. If someone is not actively
mounting an attack against you, at least the packets later on
will be encrypted and protected from snooping. So it's a bit of
a shame that this protocol that we're looking
at here-- SSL, TLS, whatever-- doesn't offer this kind of
opportunistic encryption thing. But such is life. So I guess the server
[INAUDIBLE] in this protocol. The client sometimes can and
sometimes doesn't have to. Make sense? Yeah. AUDIENCE: I'm just curious. What's to stop
someone from-- I mean, let's just say that
once a year, they create using new name key pairs. So why couldn't you kind of
try to spend that entire year for that specific key? PROFESSOR: Huh? AUDIENCE: Why does that
not work with this? PROFESSOR: I think it does work. So OK, so it's like what
goes wrong with this scheme. Like, one of the
things that we have to do with the
topography of good here, and as with Kerberos, people
start off using good crypto, but it gets worse
and worse over time. Computers get faster. There's better algorithms
that are breaking this stuff. And if people are not
diligent about increasing their standards, then
these problems do creep up. So for example, it used to be
the case that many certificates were signed. Well, there's two
things going on. There's a public key
signature scheme. And then because the public key
crypto has some limitations, you typically-- actually,
when you sign a message, you actually take a
hash of the message and then you sign the
hash itself because it's hard to sign a gigantic
message, but it's easy to sign a compact hash And one thing that
actually went wrong is that people used to
use MD5 as a hash function for collapsing the big message
here signing into a 128 bit thing that you're
going to actually sign with a crypto system. MD5 was good maybe 20 years
ago, and then over time, people discovered weaknesses
in MD5 that could be exploited. So actually, at some
point, someone did actually ask for a certificate with
a particular MD5 hash, and then they
carefully figured out another message that hashes
to the same MD5 value. And as a result, now you have a
signature by a CA on some hash, and then you have a different
message, a different key, or a different
name that you could convince someone was signed. And this does happen. Like, if you spend a lot of time
trying to break a single key, than you will
succeed eventually. If that certificate
was using crypto, that could be brute force. Another example of something
that's probably not so great now is if you're using RSA. We haven't really
talked about RSA, but RSA is one of
these public key crypto systems that allows us to
either encrypt messages or sign messages. With RSA, these
days, it's probably feasible to spend lots of money
and break 1,000 bit RSA keys. You'd probably have to
spend a fair amount of work, but it's doable, probably
within a year easily. From there, absolutely. You can ask a certificate
authority to sign some message, or you can even take
someone's existing public key and try to brute force the
corresponding secret key, or [? manual hack. ?] So you have to keep up with
the attackers in some sense. You have to use
larger keys with RSA. Or maybe you have to use
a different crypto scheme. For example, now people
don't use MD5 hashes and certificates. They use SHA-1, but that
was good for a while. Now SHA-1 is also weak,
and Google is actually now actively trying to push web
developers and browser vendors et cetera to discontinue
the use of SHA-1 and use a different hash
function because it's pretty clear that maybe in
5 or 10 years time, there will be relatively
easy attacks on SHA-1. It's already been
shown to be weaker. So I guess there is no
magic bullet, per se. You just have to
make sure that you keep evolving with the hackers. Yeah. There is a problem, absolutely. Like, all of this stuff
that we're talking about relies on crypto being correct,
or sort of being s to break. So you have to pick
parameters suitably. At least here, there's
an expiration time. So well, let's pick
some parameters that are good for a year
as opposed to for 10 years. The CA has a much
bigger problem. This key, there's no
expiration on it, necessarily. So that's less clear
what's going on. So probably, you would pick
really aggressively sort of safe parameters. So 4,000 or 6,000
bit RSA or something. Or another scheme all together. Don't use SHA-1 at all here. Yeah. No real clear answer. You just have to do it. All right. Any other questions? All right. So let's now look at-- so
this is just like the protocol side of things. Let's now look at how
do we integrate this into a particular application,
namely the web browser? So I guess if you want to secure
network communication, or sort of websites, with
cryptography, there's really three things we
have to protect in browser. So the first thing we have to
protect is data on the network. And this is almost the easy
part because well, we're just going to run a
protocol very much like what I've been describing so far. We'll encrypt all the
messages, sign them, make sure they haven't
been tampered with, all this great stuff. So that's how we're
going to protect data. But then there's two other
things in a web browser that we really have
to worry about. So the first of them
is anything that actually runs in the browser. So code that's running
in the browser, like JavaScript or
important data that's stored in the browser. Maybe your cookies, or local
storage, or lots of other stuff that goes on in a
modern browser all has to be somehow protected
from network [? of hackers. ?] And we'll see the
kinds of things we have to worry about
here in a second. And then the last thing that you
might not think about too much but turns out to be a
real issue in practice is protecting the
user interface. And the reason for this
is that ultimately, much of the confidential data
that we care about protecting comes from the user. And the user is typing this
stuff into some website, and the user probably
has multiple websites open on their computer
so that the user has to be able to distinguish
which site they're actually interacting with at
any moment in time. If they accidentally typed their
Amazon password into some web discussion forum, it's
going to be disastrous depending on how much you care
about your Amazon password, but still. So you really want to
have good user interface sort of elements that
help the user figure out what are they doing? Am I typing this confidential
data into the right website, or what's going to happen to
this data when I submit it? So this turns out to be a pretty
important issue for protecting web applications. All right. Make sense? So let's talk actually
what the current web browsers do on this front. So as I mentioned, here
for protecting [INAUDIBLE], we're just going to use this
protocol called SSL or TLS now that encrypts and
authenticates data. It looks very similar to the
kind of discussion we've had so far. It includes the certificate
authorities, et cetera. And then of course,
many more details. Like, TLS is hugely
complicated, but it's not particularly interesting
from this [INAUDIBLE] angle. All right, so protecting,
[? stopping ?] the browser turns out to be much
more interesting. And the reason is that
we need to make sure that any code or data delivered
over non-encrypted connections can't tamper with
code and data that came from an
encrypted connection because our threat model is
that anything that's unencrypted could potentially be tampered
with by a network [? backer. ?] So we have to make
sure that if we have some unencrypted JavaScript
code running on our browser, then we should assume
that that could've been tampered with an attacker
because it wasn't encrypted. It wasn't authenticated
over the network. And consequently,
we should prevent it from tampering with any
pages that were delivered over an encrypted connection. So the general plan
for this is we're going to introduce a new URL scheme. Let's call HTTPS. So you often see this in URLs,
presumably in your own life. And there's going to be two
things that-- well, first of all, the cool thing about
introducing a new URL scheme is that now, these URLs are
just different from HTTP URLs. So if you have a URL that's
HTTPS colon something something, it's a
different origin as far as the same origin policy
is concerned from regular HTTP URLs. So HTTP URLs go over
unencrypted corrections. These things are
going over SSL/TLS. So you'll never confuse
the two if the same origin policy does its job correctly. So that's one bit of a puzzle. But then you have
to also make sure that you correctly distinguish
different encrypted sites from one another. It then turns out cookies
have a different policy for historical reasons. So let's first talk
about how we're going to distinguish
different encrypted sites from one another. So the plan for that
is that actually, the host name via the URL has to
be the name in the certificate. So that's what
actually turns out that the certificate
authorities are going to sign at
the end of the day So we're going to literally
sign the host name that shows up in your URL as the name for
your web server's public key. So Amazon presumably has a
certificate for www.amazon.com. That's the name,
and then whatever the public key corresponding
to their secret key is. And this is what the
browser's going to look for. So if it gets a
certificate-- well, if it tries to connect or get
a URL that's https://foo.com, it better be the case that the
server presents a certificate for foo.com exactly. Otherwise, we'll say, well, we
tried to connect to one guy, but we actually
have another guy. That's a different
name in the certificate that we connected to. And that'll be a
certificate mismatch. So that's how we are going to
distinguish different sites from one another. We're basically
going to get the CAs to help us tell
these sites apart, and the CAs are going to
promise to issue certificates to only the right entities. So that's on the
same margin policy side, how we're going to
separate the code apart. And then as it turns out--
well, as you might remember, cookies have a slightly
different policy. Like, it's almost the same
origin, but not quite. So cookies have a
slightly different plan. So cookies have this secure flag
that you can set on a cookie. So the rules are, if a
cookie has a secure flag, then it gets sent only
to HTTPS requests, or along with HTTPS requests. And if a cookie doesn't
have a secure flag, then it applies to both
HTTP and HTTPS requests. Well, it's a little
bit complicated, right. It would be cleaner
if cookies just said, well, this is a cookie
for an HTTPS post, and this is a cookie
for HTTP host. And they're just
completely different. That would be very clear in
terms of isolating secure sites from insecure sites. Unfortunately, for
historical reasons, cookies have this weird
sort of interaction. So if a cookie is marked
secure, then it only applies to HTTPS sites. Well, there's a host
also as well, right. So secure cookies apply
only to HTTPS host URLs, and insecure cookies
apply to both. So that will be some source of
problems for us in a second. Make sense? All right. And the final bit
that web browsers do to try to help us along in
this plan is for the UI aspect, they're going to introduce
some kind of a lock icon that users are supposed to see. So there's a lock
icon in your browser, plus you're supposed to look
at the URL to figure out which site you're on. Now that's how web
browser developers expect you to think of the world. Like, if you're ever
entering confidential stuff into some website, then
you should look at the URL, make sure that's
the actual host name that you want to be
talking to, and then look for some sort of a
lock icon, and then you should assume things
are good to go. So that's the UI aspect of it. It's not great. It turns out that many
phishing sites will just include an image of a lock
icon in the site itself and have a different URL. And if you don't know
exactly what to look for or what's going on, a user
might be fooled by this. So this UI side
is a little messy, partly because users
are messy, like humans. And it's really
hard to tell what's the right thing to do here. So we'll focus mostly
on this aspect of it, which is much easier
to discuss precisely. Make sense? Any questions about
this stuff so far? Yeah. AUDIENCE: I noticed
some websites that our HTTPS [INAUDIBLE]. PROFESSOR: Yeah. So it turns out that the
browsers evolve over time what it means to get a lock icon. So one thing that
some browsers do is they give you
a lock icon only if all of the content or the
resources within your page were also served over HTTPS. So this is one of
the problems that forced HTTPS tries to
address is this mixed content or insecure
embedding kinds of problems. So sometimes, you will be fail
to get a lock icon because of that check. Other times, maybe
your certificate isn't quite good enough. So for example, Chrome will
not give you a lock icon if it thinks your certificate
uses weak cryptography. But also, it varies
with browsers. So maybe Chrome will not
give you a lock icon, but Firefox will. So it's, again,
there's no clear spec on what this lock icon means. Just people sweep stuff
under this lock icon. Other questions? All right. So let's look at h guess
what kinds of problems we run into with this plan. So one thing I guess we
should maybe first talk about is, OK, so in
regular HTTP, we used to rely on DNS to
give us the correct IP address on the server. So how much do we have to
trust DNS for these HTTPS URLs? Are DNS servers trusted,
or are these DNS mappings important for us anymore? Yeah. AUDIENCE: They are
because the certificate is signing the domain name. I don't think you sign an
IP address [INAUDIBLE]. PROFESSOR: That's right. Yeah. So the certificate
signs the domain name. So this is like amazon.com. So [INAUDIBLE]. AUDIENCE: Say someone steals
amazon.com's private key and [INAUDIBLE] another server
with another IP address, and combines [INAUDIBLE]
IP address [INAUDIBLE]. But then you already
stole the private key. PROFESSOR: That's right. Yeah. So in fact, you're
describing after both steal the private key and
redirect DNS to yourself. So is DNS in itself sensitive
enough for us to care about? I guess in some
sense you're right, that we need DNS
to find the idea, or otherwise we'd be lost
because this is just the host name, and we still need to
find IP address to talk to it. What if someone
compromised the DNS server and points us at a
different IP address? Is it going to be bad? Yeah. AUDIENCE: Well, maybe
just [INAUDIBLE] HTTPS. PROFESSOR: So potentially
worrisome, right. So they might just refuse
the connection altogether. AUDIENCE: Well, no. They just redirect
you to the HTTP URL. PROFESSOR: Well, so
certainly, if you connect to it over HTTPS,
then they can't redirect. But yeah. Yeah. AUDIENCE: You can [INAUDIBLE]
and try to fool the user. That's [INAUDIBLE]. PROFESSOR: That's right, yeah. So the thing that
you mentioned is that you could try to serve
up a different certificate. So maybe you-- well, one
possibility is you somehow compromised the CA, in
which case all right, you're in business. Another possibility is
maybe you'll just sign the certificate by yourself. Or maybe you have some old
certificate for this guy that you gotten the
private key for. And it turns out
that web browsers, as this sort of forced HTTPS
paper we're reading touched on, most web browsers actually ask
the user if something doesn't look right with the
certificate, which seems like a fairly
strange thing to do because here's the rule. The host name has to match
the name of the certificate, and it has to be valid. It has to be unexpired,
all these very clear rules. But because of historically the
way HTTPS has been deployed, it's often been the case
that web server operators mis-configure HTTPS. So maybe they just forget
to renew their certificate. Things were going
along great and you didn't notice that your
certificate was expired and you just forgot to renew it. So it seems to web
browser developers, that seems like a bit of a bummer. Oh, man. It's just expired. Let's just let
the user continue. So they offer a dialogue
box for the user saying, well, I got a
certificate, but it doesn't look right in some way. [INAUDIBLE] go ahead
anyway and continue. So web browsers will allow
users to sort of override this decision on things like
expiration of certificates. Also for host names,
it might be the case that your website has many name. Like for Amazon,
you might connect to amazon.com, or maybe
www.amazon.com, or maybe other host names. And if you are not careful
with the website operator, you might not know
to get certificates for every possible name
that your website has. And then a user is sort
of stuck saying, well, the host name doesn't
look quite right, but maybe let's go anyway. So this is the reason
why web browsers allow users to accept more
broadly, or a broader range of certificates, than these
rules might otherwise dictate. So that's [INAUDIBLE] problem. And then if you
hijack DNS, then you might be able to
redirect the user to one of these
sites that serves up a incorrect certificate. And if the user isn't
careful, they're going to potentially approve
the browser accepting your certificate, and then
you're in trouble then. That's a bit of a gray area
with respect to how much you should really trust DNS. So you certainly don't want to
give arbitrary users control of your DNS name [INAUDIBLE]. But certainly, the goal
of SSL/TLS and HTTPS, all this stuff, is to
hopefully not trust DNS at all. If everything works
here correctly, then DNS shouldn't be trusted. You can [INAUDIBLE]. You should never be able
to intercept any data or corrupt data, et cetera. Make sense? That's if everything
works, of course. It's a little bit
messier than that. All right. So I guess one interesting
question to talk about is I guess how bad
could an attack be if the user mis-approves
a certificate? So as we were saying,
if the user accepts a certificate for the wrong
host or accepts an expired certificate, what
could go wrong? How much should we worry about
this mistake from the user? Yeah. AUDIENCE: Well, [INAUDIBLE]. But it could be,
[? in example ?], not the site the user wants to visit. So they could do things like
pretend to be the user's name. PROFESSOR: Right. So certainly, the user
might then I guess be fooled into thinking,
oh, I have all this money, or you have no money at all
because the result page comes back saying here's your balance. So maybe the user
will assume something about what that bank has
or doesn't have based on the result. Well,
it still seems bad, but not necessarily
so disastrous. Yeah. AUDIENCE: I think
that an [INAUDIBLE] get all the user's
cookies and [INAUDIBLE]. PROFESSOR: Right. So this is your fear, yeah. This is much more
worrisome, actually, or has a much more longer
lasting impact on you. And the reason this works out
is because the browser, when it figures out [INAUDIBLE]
makes a decision as to who is allowed to get
a particular set of cookies or not just looks at
the host name in the URL that you were supposed
to be connected to. So if you connect to some
attackers' web server, and then you just accept their
certificate for amazon.com as the real thing,
then the browser will think, yeah, the entity
I'm talking to is amazon.com, so I will treat them as I
would a normal amazon.com server, which means that
they should get access to all the cookies that
you have for that host. And presumably they could
run a JavaScript code in your browser in that
same origin principle. So if you have
another site open that was connecting to the
real website-- like maybe you had a tab open
in your browser. You closed your laptop,
then you opened it on a different network, all of
a sudden, someone intercepted your connection to
amazon.com and injected their own response. If you approve it,
then they'll be able to access
the old amazon.com page you have open because
as far as the browser is concerned, these
are the same origin because they have
the same host name. That's going to be troublesome. So this is potentially
quite a unfortunate attack if the user makes
the wrong choice on approving that certificate. Make sense? Any questions about that? All right. So that's one sort of, I guess,
issue that this forced HTTPS paper is worried
about is users making a mistake in the decision,
users having too much leeway in accepting certificates. Another problem that
shows up in practice is that-- we sort of
briefly talked about this-- but this is one of the
things that also forced HTTPS, I think, is
somewhat concerned about is this notion of insecure
embedding, or mixed content. And the problem that
this term refers to is that a secure site, or
any website for that matter, can embed other pieces of
content into a web page. So if you have some sort of
a site, foo.com/index.html, this site might be
served from HTTPS, but inside of this HTML page,
you could have many tags that instruct the browser to go
and fetch other stuff as part of this page. So the easiest thing
to sort of think about is probably script
tags where you can say script source
equals http jquery.com. So this is a popular
JavaScript library that makes it easier to
interact with lots of stuff in your browser. But many web developers
just reference a URL on another site like this. So we should be fairly
straightforward, but what's the problem
with this kind of set up? Suppose you have a secure
site and you just load jQuery. Yeah. AUDIENCE: It could
be fake jQuery. PROFESSOR: Yeah. So there are actually
two ways that you could get the wrong thing
that you're not expecting. One possibility is that
jQuery itself is compromised. So that seems like, well,
you get what you asked for. You asked for this
site from jquery.com and that's what you get. If jQuery is compromised,
that's too bad. Another problem is
that this request is going to be sent without any
encryption or authentication over the network. So if an adversary is in control
over your network connection, then they could
intercept this request and serve back some other
JavaScript code in response. Now, this JavaScript
code is going to run as part of this page. And now, because it's running
in this HTTPS foo.com domain, it has access to your
secure cookies for foo.com and any other stuff you have
in that page, et cetera. So it seems like a
really bad thing. So you should be careful not to. Or a web developer
certainly should be careful not to make
this kind of a mistake. So one solution is to ensure
that all content embedded in a secure page is also secure. So this seems like a good
guideline for many web developers to follow. So maybe you should just
do https colon jquery.com. Or it turns out that URLs
support these origin relative URLs, which means you could omit
the HTTPS part and just say, [INAUDIBLE] script source
equals //jquery.com/ something. And what this means is to
use whatever URL scheme your own URL came from. So this tag will translate
to https jquery.com if it's on an HTTPS page, and
to regular http jquery.com if it's on a non-HTTPS,
just regular HTTP URL. So that's one way to
avoid this problem. Another thing that actually
recently got introduced. So this field is
somewhat active. People are trying to
make things better. One alternative way of
dealing with this problem is perhaps to include a hash or
some sort of an [? indicator ?] right here in the tag, because
if you know exactly what content you want to load,
maybe you don't actually have to load it all over HTTPS. You don't actually care who
serves it to you, as long as it matches a particular hash. So there's actually
a new spec out there for being able to
specify basically hashes in these kinds of tags. So instead of having to refer
to jquery.com with an HTTPS URL, maybe what you
could do is just say script source equals
jquery.com, maybe even HTTP. But here, you're going to
include some sort of a tag attribute, like
hash equals here, you're going to put in a--
let's say a shell one hash or a shell two
hash of the content that you're expecting to
get back from the server. AUDIENCE: [INAUDIBLE]. PROFESSOR: Question? AUDIENCE: [INAUDIBLE]. PROFESSOR: Ah, man. There's some
complicated name for it. I have the URL, actually, in the
lecture notes, so [INAUDIBLE]. Subresource integrity
or something like this. I can actually slowly
be-- well, hopefully will be deployed probably
soon in various browsers. Feels like another way to
actually authenticate content without relying on data, or data
encryption of the [INAUDIBLE]. So here, we have this
very generic plan using SSL and TLS to
authenticate connections to particular servers. This is almost like
an alternative way of thinking of sort of securing
your network communication. If the thing you just
care about is integrity, then maybe you don't need
a secure, encrypted channel over the network. All you need is to
specify exactly what you want at the end of the day. Yeah. AUDIENCE: So doesn't
this [INAUDIBLE]? PROFESSOR: Doesn't this
code sit at the client? Well, it runs at the client,
but the client fetches this code from some server. AUDIENCE: [INAUDIBLE]. Can't anybody just [INAUDIBLE]? PROFESSOR: Yeah. So I think the
point of the hash is to protect the containing page
from attackers that injected different JavaScript code here. So for jQuery, this
makes a lot of sense because jQuery is well known. You're not trying to hide
what jQuery source code is. Well, what you do want to
make sure is that the network attacker cannot intercept
your connection and supply a malicious version of
jQuery that's going to leak your cookies. AUDIENCE: [? Oh, ?] OK. PROFESSOR: That make sense? It's absolutely true that
anyone can compute the hash of these things for themselves. So this is a solution
for integrity problems, not for confidentiality. All right. So this is sort of what I guess
developers have to watch out for when writing pages, or
including content in their HTML pages on a HTTPS URL. Another worrisome problem
is dealing with cookies. And here's where this difference
between secure flags and just origins comes into play. So one thing, of course,
the developer could screw up is maybe they just forget
to set the secure flag on a cookie in the first place. This happens. Maybe you're thinking my users
only ever go to the HTTPS URL. My cookies are
never [INAUDIBLE]. Why should I set the
secure flag on the cookie? And they might
[? also have the ?] secure flag, or maybe
they just forget about it. Is this a problem? What if your users
are super diligent? They always visit the
HTTPS URL, and you don't have any problems like this. Do you still leave the
secure flag on your cookies? [INAUDIBLE] Yeah. AUDIENCE: Could the
attacker connect to your URL and redirect you
to a [INAUDIBLE]? PROFESSOR: Yeah. So even if the user doesn't
explicitly, manually go to some plain text URL, the
attacker could give you a link, or maybe ask you to load an
image from a non-HTTPS URL. And then non-secure
cookie is just going to be sent along
with the network request. So that seems like
a bit of a problem. So you really do
need the secure flag, even if your users and your
application is super careful. AUDIENCE: But I'm
assuming there's an HTTP URL [INAUDIBLE]. PROFESSOR: That's right, yeah. So again, so how could
this [? break? ?] Suppose I have a site. It doesn't even
listen on port 80. There's no way to
connect to me on port 80, so why is it a problem if
I have a non-secure cookie? AUDIENCE: Because the
browser wouldn't have cookies for another domain. PROFESSOR: That's right. So the browser wouldn't
send your cookie to a different domain,
but yet it still seems worrisome that an
attacker might load a URL. So suppose that amazon.com only
ever served stuff over SSL. It's not even
listening on port 80. There's no way to connect it. So in this case,
and as a result, they don't set their
secure flag on a cookie. So how could a hacker
then steal their cookie if Amazon isn't even
listening at port 80? Yeah. AUDIENCE: Can't the
browser still think it's an HTTP connection? PROFESSOR: Well, so
if you connect to port 443 and you speak SSL
or GLS, then it's always going to be encrypted. So that's not a problem. Yeah. AUDIENCE: The attacker can
[INAUDIBLE] their network. PROFESSOR: Yeah. So the attacker can actually
intercept your packets that are trying to connect
to Amazon on port 80 and then appear, and make
it appear, like you've connected successfully. So if the attacker has
control over your network, they could redirect
your packets trying to get to Amazon to their
own machine on port 80. They're going to
accept the connection, and the client isn't going to
be able to know the difference. It will be as if Amazon
is listening on port 80, and then your cookies will be
sent to this adversary's web server. AUDIENCE: Because the
client is unknown. PROFESSOR: That's right. Yeah, so for HTTP,
there's no way to authenticate the host
you're connected to. This is exactly what's going on. HTTP has no authentication,
and as a result, you have to prevent
the cookies from being sent over HTTP in
the first place because you have no idea
who that HTTP connection is going to go to if you're
assuming a network adversary. AUDIENCE: So you need
network control to do this. PROFESSOR: Well, yeah. So either you have full
control over your network so you know that adversaries
aren't going to be able to intercept your packets. But even then, it's
actually not so great. Like look at the TCP lecture. You can do all kinds of sequence
number of attacks and so on. [? That's going to be ?]
troublesome. All right. Any more questions about that? Yeah. AUDIENCE: I'm sorry, but
isn't the attack intercepted in that case? Is there like a redirect? PROFESSOR: Well, what
that hacker presumably would intercept is an HTTP
request from the client going to http amazon.com, and
that request includes all your amazon.com cookies,
or cookies for whatever domain it is that you're
sending your request to. So if you don't mark
those cookies as secure, there will be set of both
encrypted and unencrypted connections. AUDIENCE: So how does that
request get initiated? PROFESSOR: Ah, OK. Yeah. So maybe you get the user
to visit newyorktimes.com and you pay for an advertisement
that loads an image from http colon amazon.com. And there's nothing
preventing you from saying, please load
an image from this URL. But when a browser
tries to connect there, it'll send the cookies if
the connection succeeds. Question back there. AUDIENCE: Will it ask
for a change [INAUDIBLE]? PROFESSOR: Yeah. So HTTPS everywhere
is an extension that is very similar to
forced HTTPS in some ways, and it tries to prevent
these kinds of mistakes. So I guess one thing
that forced HTTP does is they worry about
such mistakes. And when you sort of opted a
site into this forced HTTPS plan, one thing that the
browser will do for you is prevent any HTTPS
connections to that host in the first place. So there's no way to make
this kind of mistakes of not flagging your
cookie as secure, or having other sort of kinds
of cookie problems as well. Another more subtle
problem-- so this, the problem we
talked about just now is the developer
forgetting to set the secure flag on a cookie. So that seems fixable. OK, maybe the developer
should just do it. OK, fix that problem. The thing that's
much more subtle is that when a secure web
server gets a cookie back from the client, it actually has
no idea whether this cookie was sent through an encrypted
connection or a plain text connection because
when the server gets a cookie from the
client, all it gets is the key value
pair for a cookie. And as we sort of look at here,
the plan for the [INAUDIBLE] follows is that it'll include
both secure and insecure cookies when it's sending a
request to a secure server, because the browser
here was just concerned about the
confidentiality of cookies. But on the server
side, you now don't have any integrity guarantees. When you get a
cookie from a user, it might have been sent over
an encrypted connection, but it also might have been sent
over a plain text connection. So this leads to somewhat
more subtle attacks, but the flavor of
these attacks tend to be things like
session fixation. What it means is that suppose I
want to see what emails you're sending. Or maybe I'll set a
cookie for you that is a copy of my Gmail, cookie. So when you go to compose
a message in Gmail, it'll actually be saved in
my sent folder inside of your sent folder. It'll be as if you're
using my account, and then I'll be able to
extract things from there. So if I can force a session
cookie into your browser and sort of get you
to use my account, maybe I can extract some
information that way from the victim. So that's another problem that
arises because of this grey area [INAUDIBLE] incomplete
separation between HTTP and HTTPS cookies. Question. AUDIENCE: So you would need
a [INAUDIBLE] vulnerability to set that cookie [INAUDIBLE]. PROFESSOR: No.
[INAUDIBLE] vulnerability to set this cookie. You would just trick the
browser into connecting to a regular HTTP host URL. And without some extension
like forced HTTPS or HTTPS everywhere, you could
then, as an adversary, set up a key in
the user's browser. It's a non-secure
cookie, but it's going to be sent back,
even on secure requests. AUDIENCE: So do you have to
trick the browser into thinking the domain is the same domain? PROFESSOR: That's right. Yeah. So you have to intercept
their network connection and probably do the
same kind of attack you were talking about just
a couple of minutes ago. Yeah. Make sense? All right. So I guess there's
probably [INAUDIBLE]. So what does forced HTTPS
actually do for us now? It tries to prevent some
subset of these problems. So I guess I should say, so
forced HTTPS, the paper we read was sort of a
research proposal that was published I guess
five or six years ago now. Since then, it's actually
been standardized and actually adopted. So this was like a somewhat
sketchy plug-in that stored stuff and some cookies. Are they worried about
getting evicted and so on? Now actually, most
browsers look at this paper and say, OK, this
is a great idea. We'll actually
implement it better within the browser itself. So there's something called HTTP
strict transport security that implements most of the
ideas from forced HTTPS and actually make a good story. Like, here's how research
actually makes an impact on I guess security of web
applications and browsers. But anyway, let's look
at what forced HTTPS does for a website. So forced HTTPS allows a
website to set this bit for a particular host name. And the way that forced
HTTPS changes the behavior of the browser is threefold. So if some website
sets forced HTTPS, then there's sort of three
things that happen differently. So any certificate
errors are always fatal. So the user doesn't
have a chance of accepting incorrect
certificate that has a wrong host name, or an
expiration time that's passed, et cetera. So it's one thing that
the browser now changes. Another is that it redirects
all HTTP requests to HTTPS. So this is a pretty good idea. If you know a site is always
using HTTPS legitimately, then you should probably
prohibit any regular HTTP requests [? website ?],
because that's probably a sign of some mistake
or attacker trying to trick you into connecting
to a site without encryption. You want to make sure this
actually happens before you issue the HTTP request. Otherwise, the HTTP request
has already sort of sailed onto the network. And the last thing that this
forced HTTPS setting changes is that it actually prohibits
this insecure embedding plan that we looked
at below here when you're including a
HTTP URL in an HTTPS site. Make sense? So this is what the forced
HTTPS sort of extension did. In terms of what's
going on now is that well, so this HTTPS
strict transport security HSTS protocol basically
does the same things. Most browsers now prohibit
insecure embedding by default. So this used to be a
little controversial because many developers
have trouble with this. But I think Firefox and Chrome
and IE all now by default will refuse to load
insecure components, or at least secure JavaScript
and CSS, into our page unless you do something. Question. AUDIENCE: Don't they
prompt the user? PROFESSOR: They used to, and
the user would just say, yes. So IE, for example, used to
pop up this dialogue box, and this paper
talks about, saying, would you like to load
some extra content, or something like that. AUDIENCE: [INAUDIBLE]
because [INAUDIBLE]. PROFESSOR: Yeah. I think if you try to
pretend to be clever, then you can bypass all
these security mechanisms. But don't try to
be clever this way. So this is mostly a
non-problem in modern browsers, but these two things
are still things that forced HTTPS and HTTP
strict transport security provide and are useful. Yeah. AUDIENCE: What happens
when a website can't support HTTPS? [INAUDIBLE]
change their [INAUDIBLE]? PROFESSOR: So what do you
mean can't support HTTPS? AUDIENCE: [INAUDIBLE]. PROFESSOR: Well, OK. So if you have a website
that doesn't support HTTPS but sets this
cookie, what happens? AUDIENCE: [INAUDIBLE]. PROFESSOR: Yeah. So this is the reason
why it's an option. So if you opted everyone, then
you're exactly in this boat. Like, oh, all of a sudden, you
can't talk to most of the web because they don't use HTTPS. So you really wanted this
to be selectively enabled for sites that really want
this kind of protection. Yeah. AUDIENCE: But also, if
I remember correctly, you can't set the cookie
unless the site [INAUDIBLE]. PROFESSOR: That's right, yeah. So these guys are also
worried about denial of service attacks,
where this plug in could be used to cause
trouble for other sites. So if you, for example,
set this forced HTTPS bit for some unsuspecting
website, then all of a sudden, the website stops working
because everyone is now trying to connect
to them over HTTPS, and they don't support HTTPS. So this is one example
of worrying about denial of service attacks. Another thing is
that they actually don't support setting forced
HTTPS for an entire domain. So they worried that, for
example, at mit.edu, I am a user at mit.edu. Maybe I'll set a forced HTTPS
cookie for start.mit.edu in everyone's browsers. And now, only HTTPS
things work at MIT. That seems also a
little disastrous, so you probably
want to avoid that. On the other hand, actually,
HTTPS strict transfer security went back on this
and said, well, we'll allow this notion of forcing
HTTPS for an entire subdomain because it turns out
to be useful because of these insecure cookies
being sent along with a request that you can't tell where
they were sent from initially. Anyway, so there's all
kinds of subtle interactions with teachers at
the lowest level, but it's not clear what
the right choice is. OK, so one actually interesting
question you might ask is are these fundamental
to the system we have, or are these mostly
just helping developers avoid mistakes? So suppose you had a
developer that's very diligent and doesn't do insecure
[INAUDIBLE] embedding, doesn't solve any
other problems, always gets their
certificates renewed, should they bother with
forced HTTPS or not? Yeah. AUDIENCE: Well, yeah. You still have the problem with
someone forcing HTTP protocol. Nothing stops the
hacker from doing [? excessive ?]
[INAUDIBLE] forces the user to load something
over HTTP and then to intercept the connection. PROFESSOR: That's true, but if
you feel they're very diligent and all their cookies
are marked secure, then having someone visit an
HTTP version of your site, shouldn't be a problem. AUDIENCE: [INAUDIBLE]. PROFESSOR: Yeah. So you'd probably have to
defend against cookie overwrite or injection attacks, and
that's sort of doable. It's a little tedious, but
you can probably do something. AUDIENCE: Yeah. I think her point is that
also, it didn't-- security didn't check the
certificate, right? PROFESSOR: Yeah. So that's one. I think that this
is the biggest thing is this first point, which
is that everything else, you can sort of defend it
against by cleverly coding or being careful in
your application. The first thing is
something that the user has-- or the developer--
has no control over because the developer
wants to make sure, for example, that their cookie will only
be sent to their server as signed by this CA. And if the user is allowed
to randomly say, oh, that's good enough,
then the developer has no clue where
their cookie's going to end up because some
user is going to leak it to some incorrect server. So this is, I think, the main
benefit of this protocol. Question back there. AUDIENCE: [INAUDIBLE]
second point is also vital because the
user might not [INAUDIBLE]. You might [INAUDIBLE]
of the site, which would be right in the middle. PROFESSOR: I see. OK. So I agree in the
sense that this is very useful from the
point of view of UI security because as far as the
cookies are concerned, the developer can
probably be clever enough to do something sensible. But the user might not
be diligently looking at that lock icon
and URL at all times. So if you load up
amazon.com and it asks you for a credit card number,
you might just type it in. You just forgot to
look for a lock icon, whereas if you set forced
HTTPS for amazon.com, then there's just not
chance that you'll have an HTTP URL for that site. It still [? causes a ?]
problem that maybe the user doesn't read the URL correctly. Like it says Ammazon
with two Ms dot com. Probably still fool many users. But anyway, that is another
advantage for forced HTTPS. Make sense? Other questions
about this scheme? All right. So I guess one
interesting thing is how do you get this
forced HTTPS bit for a site in the first place? Could you have intercepted
that as an attacker and prevent that
bit from being set if you
[? want to mount a fax? ?] Yeah. AUDIENCE: [INAUDIBLE] HTTPS. I mean, HTTPS, we're
[? assuming ?] [INAUDIBLE] protocol [INAUDIBLE]. PROFESSOR: That's right. So on one hand,
this could be good. But this forced
https that can only be sent over HTTPS connection
to the host in question. On other hand, the user might
be fooled at that point. Like, he doesn't have
the forced HTTPS bit yet. So maybe the user will allow
some incorrect certificate, or will not even know that
this is HTTP and not HTTPS. So it seems potentially
possible for an attacker to prevent that forced
HTTPS bit from being sent in the first place. If you've never been to a site
and you try to visit that site, you might never learn whether
it should be forced HTTPS or not in the first place. Yeah. AUDIENCE: Will the [INAUDIBLE]
roaming certificate there. PROFESSOR: That's right, yeah. So I guess the way to think
of it is if they did a set, then you know you talked to
the right server at some point, and then you could continue
using that bit correctly. On the other hand, if you don't
have that bit set, or maybe if you've never talked
to a server yet, there's no clear cut
protocol that will always give you whether that forced
HTTPS bit should be set or not. Maybe amazon.com always wants
to set that forced HTTPS bit. But the first time you
pulled up your laptop, you were already on
an attacker's network, and there's just no way for
you to connect to amazon.com. Everything is intercepted,
or something like this. So it's a very hard
problem to solve. The bootstrapping of
these security settings is pretty tricky. I guess one thing
you could try to do is maybe embed
this bit in DNSSEC. So if you have DNSSEC,
already in use, then maybe you could sign
whether you should use HTTPS or not, or forced HTTPS or
not, as part of your DNS name. But again, it just boils
down the problem to DNSSEC being secure. So there's always this
sort of rule of trust where you have to really
assume that's correct. Question. AUDIENCE: [INAUDIBLE]. PROFESSOR: Yeah. So I guess Google keeps
trying to improve things by hard coding it. So one thing that
Chrome offers is that actually, the browser
ships with a list of sites that should have forced HTTPS
enabled-- or now, well, this HSTS thing, which is
[INAUDIBLE] enabled. So when you actually
download Chrome, you get lots of
actually useful stuff, like somewhat up to date CRL
and a list of forced HTTPS sites that are
particularly important. So this is like somewhat
admitting defeat. Like the protocol doesn't work. We just have to distribute
this a priori to everyone. And it sets up this
unfortunate dichotomy between sites that are
sort of important enough for Google to ship
with the browser, and sites that don't do this. Now of course, Google
right now tells you that anyone can get
their site included because the list is so small. But if this grows to
millions of entries, I'm sure Google
will stop including everyone's site in there. But yeah, you could
totally add a domain. And you could email
Chrome developers and get your thing included on
the list of forced HTTPS URLs. Anyway, any other questions
about forced HTTPS and SSL? All right. Good. So I'll see you guys on
Wednesday at the [INAUDIBLE].
