MIT course "Computer Systems Security". Lecture 14: "SSL and HTTPS", part 3

Massachusetts Institute of Technology. Lecture course # 6.858. "Security of computer systems". Nikolai Zeldovich, James Mykens. year 2014

Computer Systems Security is a course on the development and implementation of secure computer systems. Lectures cover threat models, attacks that compromise security, and security methods based on the latest scientific work. Topics include operating system (OS) security, capabilities, information flow control, language security, network protocols, hardware protection and security in web applications.

Lecture 1: "Introduction: threat models" Part 1 / Part 2 / Part 3
Lecture 2: "Control of hacker attacks" Part 1 / Part 2 / Part 3
Lecture 3: "Buffer overflow: exploits and protection" Part 1 / Part 2 / Part 3
Lecture 4: "Separation of privileges" Part 1 / Part 2 / Part 3
Lecture 5: "Where Security Errors Come From" Part 1 / Part 2
Lecture 6: "Opportunities" Part 1 / Part 2 / Part 3
Lecture 7: "Sandbox Native Client" Part 1 / Part 2 / Part 3
Lecture 8: "Model of network security" Part 1 / Part 2 / Part 3
Lecture 9: "Web Application Security" Part 1 / Part 2 / Part 3
Lecture 10: "Symbolic execution" Part 1 / Part 2 / Part 3
Lecture 11: "Ur / Web programming language" Part 1 / Part 2 / Part 3
Lecture 12: "Network Security" Part 1 / Part 2 / Part 3
Lecture 13: "Network Protocols" Part 1 / Part 2 / Part 3
Lecture 14: "SSL and HTTPS" Part 1 / Part 2 / Part 3

I think that enforcing HTTPS is due to concerns about users who have too much leeway in making decisions about the possibility of using certificates.
')
Another problem that manifests itself in practice and which also forces the use of HTTPS, is unsafe attachment or mixed content on a web page. The meaning of this problem is that a secure website or any website, for that matter, can embed other pieces of content into a web page.

So if you have a website, for example foo.com/index.html, then it can be served via HTTPS, but inside the HTML page you can have a lot of tags that force the browser to go somewhere and make it part of This page has some other content.



The tag of such a script looks like this:

<script scr = «http://jquery.com/…”> 

And points to the source jquery.com. Thus, the popular JavaScript library facilitates the interaction of many things in your browser. But many web developers simply link to the URL of another site. It simplifies things, but what could be the catch? Suppose you have a secure site and simply load jQuery from there.

Student: it could be fake jQuery.

Professor: yes it is. In fact, there are two possibilities to get the wrong thing that you do not expect to receive. One possibility is that jQuery itself can be compromised. You got something similar to what you asked for. If jQuery is compromised, then this is very bad. Another possibility is that this request will be sent over the network without any encryption or authentication. Therefore, if the adversary controls your network connection, he can intercept this request and send you another JavaScript code in response, and now this JavaScript code will work as part of your page. And since it works in this HTTPS domain foo.com, it has access to your secure cookies foo.com and to any other thing on this page. It looks like it is really bad, so be careful. And the web developer must also be careful not to make this kind of mistake.

Thus, one solution is to ensure the security of all content embedded in a secure page. This is a good reference point that many web developers should follow. So maybe you should just use jquery.com in this line instead of jquery.com . Or if the URLs support the origin policy, this means that you can omit the HTTPS part and just say that the origin of this script is //jquery.com/, that is, scr = "//jquery.com/…".



And this means that this tag will send you to jquery.com if it is on the HTTPS page, and to jquery.com if it is not on HTTPS, but on the usual HTTP URL. This is one way to avoid such a problem.

However, people are constantly trying to improve everything, so one of the alternative ways to solve this problem may be to include a hash or something like an indicator right here in the tag:

 <script scr = «http://jquery.com/…”> 

Because if you know what kind of content you want to download, you may not need to download it completely over HTTPS. In fact, you do not care who provides you with this content as long as it corresponds to a particular hash.

Thus, there is a new specification that allows customizing hashes for tags of this type. So instead of referring to jquery.com from the HTTPS URL, you could just say that the script source is jquery.com or even HTTP, but at the end of the script you add some kind of tag attribute, for example, hash is equal to what you hoping to get from the server.



Student: what is the name of this specification?

Professor: she has a complex name, it is in the notes to the lecture notes, something like “integrity of the subresource”, Subresource integrity. It is being implemented quite slowly, but I hope that in the near future it will be applied in various browsers. This is similar to another way to perform content authentication without relying on data encryption at the network level.

Thus, we have this very general plan, using SSL and TLS to authenticate connections to a specific server. This is an alternative way to secure a network connection. If you care about integrity, you may not need a secure, encrypted network channel. All you need is to specify what exactly you want to get in the end.

Student: Doesn't this SRC code come from a client?

Professor: he works on the client side, but the client receives this code from some server.

Student: Can't anyone just type in their JavaScript

Professor: I think maybe. Therefore, the meaning of the hash is to protect the content of the page from intruders who are trying to enter other JavaScript code. For jQuery, this is very important, because jQuery is well known, because you are not trying to hide the jQuery source code. Therefore, you want to make sure that the network intruder cannot intercept your connection and insert a malicious version of jQuery, which will contribute to the leakage of cookies. It’s perfectly true that anyone can figure out for themselves the hash of these things. Thus, this is a solution to integrity problems, not confidentiality.

I think that developers should keep an eye on this when they write pages or include the content of their HTML pages in HTTPS URLs. Another problem worrying us is related to cookies. Here comes the difference between cookies with security flags and just cookies with origin of origin. The only thing that a developer can spoil here is simply to forget to set the flag on cookies first, it happens. Perhaps he thinks only of users who will only go to the HTTPS URL, and considers the installation of flags unnecessary. Is this a problem? If your users are very careful and always visit the HTTPS URL, there is no problem. Do you think it makes sense in this case to leave the security flag on your cookies?

Student: can an attacker be able to connect to your URL and redirect you to a malicious site?

Professor: yes. Even if the user explicitly manually switches to a URL in plain text, the attacker can still give him a link to an insecure site or ask him to download an image from a URL other than HTTPS. And then unprotected cookies will be sent along with the network request. So this is a problem, and you really need a flag, even if your users and your applications are very careful.

Student: I assume that there are secure HTTP URLs.
Professor: yes, that's true. Suppose I have a website that does not even listen on port 80, and there is no way to connect to me through port 80, so why can there be a problem if I use unprotected cookies?

Student: because the browser will not be able to send your cookies to another domain.

Professor: quite right, the browser will not send cookies to another domain, but there is still the danger that an attacker could load his URL. So, suppose amazon.com uses only SSL, it does not even listen on port 80. As a result, they do not set their secure flag on the cookie. So how can a hacker steal their cookies if Amazon doesn't even listen on port 80?

Student: Could the browser still think this is an HTTP connection?

Professor: Well, if you connect to port 443 and use SSL or TLS, the connection will always be encrypted, so this is not a problem.

Student: The attacker can intercept the connection.

Professor: Yes, an attacker can intercept your packets that are trying to connect to Amazon through port 80, and make it appear as if you have successfully connected to the site. So if an attacker has control over your network, he can redirect your packets to Amazon, on port 80 of his own machine, and the client will not be able to see the difference. It will look as if Amazon was listening on port 80, but in reality your cookies will be sent to this hacker's web server.

Student: because the client is unknown.

Professor: quite right, since HTTP has no way to verify the authenticity of the host to which you are connected. This is exactly what is happening. HTTP is not authenticated. Therefore, if you assume the presence of a network adversary, you should first of all prevent sending your cookies via HTTP, because you have no idea who this HTTP connection will go to.

Student: for this you need to control the network.

Professor: yes, of course. If you have complete control over your network, then you know that opponents will not be able to intercept your packets. However, even with full control over the network, you may be in trouble, look at the lectures on TCP, there were considered various types of network attacks.

Audience: But is it not possible to prevent a redirection attack in this case?

Professor: The hacker will probably intercept the client's http request at amazon.com , and this request will include all your cookies for amazon.com, or cookies for any other domain to which you are sending the request. Therefore, if you do not mark these cookies as secure, they can be sent either by encrypted or unencrypted connection.

Student: how is this request initiated?

Professor: maybe you can get a user to visit newyorktimes.com, where you paid for an ad that uploads an image from amazon.com . And there is nothing that would protect the user from the request: “please upload an image from this URL”. But when the browser tries to connect to the site, it will send cookies if the connection was successful.

There is an extension of HTTPS Everywhere, which is very similar to Force HTTPS, or forced HTTPS, and which tries to prevent this kind of error. When you select a site in HTTPS forced mode, the browser will first of all prevent any HTTP connections to this host.



Thus, there is no way to not mark your cookies as safe or to make a similar error. If the developer forgot to set the security flag on the cookie, in this case the solution is obvious - he should just fix his mistake. But there is a more delicate problem: when the secure web server receives the client’s cookie back, he has no idea whether this cookie was sent via an encrypted or simple text connection. Because in fact, the server receives only a couple of key values ​​for the cookie.

From the above action plan, it follows that when sending a request to a secure server, the browser will include both secure and non-secure cookies in it, because for its part, it is concerned about their privacy. But on the server side there are no guarantees of confidentiality, and when the server receives the user's cookies, they can be sent over an encrypted as well as a text connection. This leads to the possibility of such a type of attack as session fixation.

This means that an attacker, for example, wants to see which emails you send. To do this, he will set you his cookies, which are a copy of his Gmail account. And when you send your letter, it will appear in its Sent Items folder, and not in your folder. It will be as if you were using the attacker's account, so he can retrieve your correspondence from his inbox. So if the hacker forcibly places session cookies in your browser, it will force you to use his account. So this is another problem that arises due to misunderstandings with incomplete separation of HTTP and HTTPS cookies.

Student: but in order to insert your cookies into another browser, you need to have a vulnerability there.

Professor: No, you do not need a vulnerability to set your cookie. You are just fooling the browser so that it connects to the usual HTTP URL for the host. And if there is no extension in the browser, such as Force HTTPS or HTTPS Everywhere, you, as an attacker, could install the key in the user's browser. This is an unsecured cookie, but it will be sent back, even by secure requests.

Student: how can you make the browser think that this domain is the same domain?
Professor: for this you have to intercept the network connection and make one of the types of attacks that we talked about a few minutes ago.

So what exactly does enforced https do? He is trying to prevent some of the many problems. Studies on the Force HTTPS protocol were published 5 or 6 years ago. Since then, it has been standardized and actually adopted. It looks like a sketchy plugin that stores some things and some cookies. Today, most browser developers believe that creating it was a good idea. It is best to integrate it directly into the browser. There is something called HTTP Strict Transport Security, or HSTS, a mechanism that forcibly activates a secure connection through the HTTPS protocol. This is a good example of how scientific research affects the security of web applications and browsers.

Let's see what Force HTTPS does for a website. Forced HTTPS allows a website to set this bit for a particular host name, and there are three things that Force HTTPS affects browser behavior with.

The first is that any certificate errors are always fatal. Thus, the user has no chance to accept the wrong certificate with the wrong host name or expired, and so on. This is one thing that changes the browser.

The second thing is that Force HTTPS redirects all HTTP requests to HTTPS. This is a pretty good idea. If you know that the site always legally uses HTTPS, then you should probably deny any regular HTTP requests, because this may be a sign of some kind of error or an indication that the attacker is trying to deceive you by offering to connect to the site without encryption . You want to make sure that this actually happens before the HTTP request is executed, otherwise any HTTP request would go to the network.

And the last thing Force HTTPS forces the browser to do is that it prohibits an unsafe embedding plan that we looked at earlier — when you embed an HTTP URL into an HTTPS site.



So this is what the Force HTTPS extension does. Based on the terminology used today, the HSTS protocol does the same. Now, most browsers by default prohibit unsafe embedding. This was controversial, as many developers had problems with Force HTTPS, but I think Firefox, Chrome and IE will refuse to download unsafe components by default, or at least unsafe JavaScript and CSS to your page, if you do something wrong.

Student: they do not ask the user to perform an action?

Professor: they are used to, that usually the user agrees. For example, IE uses a pop-up dialog box that asks if you want to download additional content, or something like that. I think that if you try, you can bypass all these security measures, but I do not advise you to do this. Thus, modern browsers are trying to solve some of the problems using Force HTTPS and HSTS.

Student: What happens when a site does not support HTTPS?

Professor: what do you mean?

Student: the fact that the browser will not connect to the site via HTTPS.

Professor: what happens if you have a website that does not support HTTPS, but installs these cookies? The fact is that if you use this option in your browser, you will not be able to talk to most of the Internet, because they do not use HTTPS. Therefore, the browser should be able to communicate over HTTPS with those sites that really want this protection.

Student: if I remember correctly, you cannot set a cookie until the site allows it.

Professor: yes, that's true. These guys are worried about DoS attacks, in which this plugin can be used to cause trouble to other sites. For example, if you set the Force HTTPS bit for some unsuspecting websites, they would suddenly stop working, because now everyone would try to connect to them via HTTPS, which they don’t support. So this is one of the examples that makes you worry about the possibility of using DoS attacks by applying forced HTTPS for sites that do not count on it.

Another thing is that this protocol does not support the use of Force HTTPS for the entire domain. For example, I am a user of mit.edu who installed the Force HTTPS cookies in all browsers, and now only HTTPS connections work in MIT. This seems a bit catastrophic, so you probably want to avoid this situation.

On the other hand, the HSTS protocol has returned to this, saying that Force HTTPS can be set for the entire subdomain, because it turns out to be useful for unsafe cookies sent with the request if you do not know where they were originally sent from. There is a whole bunch of settings for these things at the lowest level, but it's still unclear what in this case means the right choice.

There is an interesting question you could ask: are these improvements fundamental or are they aimed only at helping developers avoid mistakes? Suppose you have a very responsible developer who does not perform dangerous actions, updates certificates in time, prepares new ones - should he use Force HTTPS?

Student: Of course, because nothing will stop the hacker, who will force the user to download something via HTTP, and then intercept the connection.

Professor: that's true. But if you feel that he is very diligent, and all his cookies are marked as secure, then if someone visits the HTTP version of your site, this should not cause a problem.



However, you may still need to protect yourself from overwriting cookies or injection attacks. It's tiring, but you can probably do something about it.

Student: I think the developer in any case will not be able to verify the authenticity of the certificate, right?

: , : « ». , , , , , . : «, !», , , - - . , .

: , , HTTP HTTPS, , , .

: , UI, - , . URL-. amazon.com, , , . HTTPS amazon.com, HTTP URL . , URL-, , amazonn.com amazon.com. . , Force HTTPS.



– Force HTTPS ? ?

: , .

: . , , Force HTTPS HTTPS . , . , Force HTTPS, , , HTTP, HTTPS. , HTTPS. , , HTTPS.

: Force HTTPS?

: , , , . , , , , , , , Force HTTPS .

, amazon.com Force HTTPS, , , , amazon.com, .



. DNSSEC. DNSSEC, , , , HTTPS Force HTTPS, DNS-. , DNSSEC, , , .

Google , . , Chrome , Force HTTPS. Chrome, , CRL Force HTTPS, . , , , . , Google, , , .

Of course, now Google says that any site can be included in the browser, because the existing list is very small, but if it grows to millions of entries, I’m sure Google will stop including all sites in the browser list. But now you can actually add your domain to it by simply sending an email to Chrome developers, and your website will be listed as Force HTTPS URLs.


Full version of the course is available here .

Thank you for staying with us. Do you like our articles? Want to see more interesting materials? Support us by placing an order or recommending to friends, 30% discount for Habr users on a unique analogue of the entry-level servers that we invented for you: The whole truth about VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps from $ 20 or how to share the server? (Options are available with RAID1 and RAID10, up to 24 cores and up to 40GB DDR4).

VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps until December for free if you pay for a period of six months, you can order here .

Dell R730xd 2 times cheaper? Only we have 2 x Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 TV from $ 249 in the Netherlands and the USA! Read about How to build an infrastructure building. class c using servers Dell R730xd E5-2650 v4 worth 9000 euros for a penny?