Seven misunderstandings about HTTPS

Seven misunderstandings about HTTPS

When developing webpages, you often need to observe HTTP Communication.

I use two main tools: Firebug in Firefox and Fiddler in IE. However, I have always heard people say that paid software HttpWatch is the best tool in this regard.

A few days ago, the official website of HttpWatch published a good article to clarify some misunderstandings of the HTTPS protocol. After learning, I have gained a lot of knowledge about encrypted webpage communication.

 

Seven misunderstandings about HTTPS

Http://blog.httpwatch.com/2011/01/28/top-7-myths-about-https/

Translator: Ruan Yifeng

Misunderstanding 7: HTTPS cannot be cached

Many people think that for security reasons, the browser will not save the HTTPS cache locally. In fact, as long as a specific command is used in the HTTP header, HTTPS can be cached.

Eric Lawrence, Microsoft's IE Project Manager, wrote:

"It may be shocking to say that as long as the HTTP header permits this, all versions of IE cache HTTPS content. For example, if the header command is Cache-Control: max-age = 600, the web page will be cached by IE for 10 minutes. The cache policy of IE has nothing to do with whether or not to use HTTPS protocol. (The behavior of other browsers in this respect is inconsistent depending on the version you are using, so we will not discuss it here .)"

Firefox caches HTTPS only in memory by default. However, as long as the header command contains Cache-Control: Public, the Cache will be written to the hard disk. The following figure shows that Firefox's hard disk Cache contains HTTPS content, and the header command is Cache-Control: Public.

Misunderstanding 6: SSL certificates are expensive

If you search online, you will find a lot of cheap SSL certificates, about $10 a year, which is about the same as the annual fee for A. com domain name. In fact, you can also find a free SSL certificate.

In terms of effectiveness, cheap certificates are certainly worse than certificates issued by large organizations, but almost all mainstream browsers accept these certificates.

Misunderstanding 5: the HTTPS site must have an exclusive IP Address

 

As IPv4 is about to be allocated, many people are concerned about this issue. Each IP Address can only install one SSL certificate. However, if you use a wildcard SSL certificate (wildcard SSL certificate, the price is about $125 per year), you can deploy multiple HTTPS subdomains on one IP address. For example, https://www.httpwatch.com and https://store.httpwatch.com share the same IP address.

 

In addition, UCC (Unified Communication Certificate, uniied Communications Certificate) supports a Certificate that matches multiple sites at the same time, and can be a completely different domain name. SNI (Server Name Indication) allows multiple certificates to be installed on multiple domain names on one IP address. Server, Apache, and Nginx support this technology, which is not supported by IIS. Support for clients, IE 7 +, Firefox 2.0 +, Chrome 6 +, Safari 2.1 +, and Opera 8.0 +.

Misunderstanding 4: purchase a new certificate when transferring servers

To deploy an SSL Certificate, perform the following steps:

1. Generate a CSR file (SSL Certificate Request file, SSL Certificate Signing Request) on your server ).

2. Use the CSR file to purchase an SSL certificate.

3. Install the SSL certificate.

These steps have been carefully designed to ensure transmission security and prevent unauthorized access to the certificate. The result is that the certificate you obtained in step 2 cannot be used on another server. To do this, you must output the Certificate in another format.

For example, IIS generates a transfer-able. pfx file and password-protected it.

Pass this file to other servers and you will be able to continue using the original SSL certificate.

Misunderstanding 3: HTTPS is too slow

Using HTTPS will not make your website faster (in fact, it is possible, please refer to the following), but there are some tips that can greatly reduce extra costs.

First, as long as the text content is compressed, the CPU resources consumed by decoding will be reduced. However, for contemporary CPUs, this overhead is not worth mentioning.

Second, establishing an HTTPS connection requires additional TCP round-trip, so some new bytes are sent and received. However, we can see that the number of new bytes is very small.

When you open the web page for the first time, the HTTPS protocol will be a little slower than the HTTP protocol, because it is time to read and verify the SSL certificate. The following is a waterfall chart of the HTTP webpage opening time.

 

After the same web page uses the HTTPS protocol, the opening time becomes longer.

The connection is about 10% slower. However, once a valid HTTPS connection is established and the web page is refreshed, there is almost no difference between the two Protocols. First, refresh the HTTP protocol:

Then the HTTPS protocol:

Some users may find that HTTPS is faster than HTTP. This occurs in the internal LAN of some large companies, because the company's gateways usually intercept and analyze all network communication. However, when it encounters an HTTPS connection, it can only be opened directly, because HTTPS cannot be interpreted. HTTPS is faster because this process is missing.

Misunderstanding 2: with HTTPS, cookies and query strings are secure.

Although you cannot directly read cookies and query strings from HTTPS data, you still need to make their values unpredictable.

For example, a British bank used to directly represent the session id in an ordered number:

Hackers can first register an account, find the cookie, and see the representation of this value. Then, modify the cookie to hijack the session id of another person. The query string can also be leaked in a similar way.

Misunderstanding 1: only the registration logon page requires HTTPS

This idea is common. People think that HTTPS can protect users' passwords. The new Firefox plug-in Firesheep proves this idea is wrong. We can see that on Twitter and Facebook, it is very easy to hijack others' sessions.

Free WiFi in the cafe is an ideal hijacking environment for two reasons:

1. This type of WiFi is usually not encrypted, so it is easy to monitor all traffic.

2. WiFi usually uses NAT for address translation between the Internet and the Intranet. All Intranet clients share an Internet address. This means that the hijacked session looks like a hacker from the past.

Take Twitter as an example. Its logon page uses HTTPS, but after logon, other pages become HTTP. In this case, the session value in the cookie is exposed.

 

That is to say, these cookies are established in the HTTPS environment, but are transmitted in the HTTP environment. If someone hijacks these cookies, then he can speak on Twitter as you do.