Seven misunderstandings in HTTPS _ related tips

Myth Seven: HTTPS cannot be cached

Many people believe that browsers do not save HTTPS caching locally for security reasons. In fact, HTTPS can be cached as long as a specific command is used in the HTTP header.

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

"It may be shocking, as long as the HTTP headers allow this, all versions of IE cache HTTPS content." For example, if the header command is cache-control:max-age=600, then the Web page will be cached by IE for 10 minutes. The caching policy for IE is not related to the use of HTTPS protocol. (Other browsers are inconsistent in this respect, depending on the version you are using, so this is not discussed here.) ）"

Firefox defaults to caching HTTPS only in memory. However, as long as there is a cache-control:public in the header command, the cache is written to the hard disk. The following picture shows that Firefox's hard disk cache has HTTPS content, and the header command is cache-control:public.

Myth Six: SSL certificates are expensive

If you search the Internet, you will find a lot of cheap SSL certificates, about 10 dollars a year, this and a. com domain name of the annual fee is similar. And in fact, you can find a free SSL certificate.

In effect, a cheap certificate is certainly a little less than a certificate issued by a large organization, but almost all mainstream browsers accept these certificates.

Myth Five: HTTPS site must have exclusive IP address

Since IPv4 will be allocated, many people are concerned about the problem. There is no doubt that only one SSL certificate can be installed per IP address. However, if you use a Subdomain wildcard SSL certificate (wildcard SSL certificate, which 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 Communications Certificate, Unified 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 one IP address by a number of domain names. Server-side, Apache and Nginx support this technology, not supported by IIS, client, IE 7+, Firefox 2.0+, Chrome 6+, Safari 2.1+, and opera 8.0+ support.

Myth four: To purchase a new certificate when transferring a server

Deploying an SSL certificate requires a few steps:

1. On your server, generate a CSR file (SSL certificate request file, SSL certificate signing requests).

2. Use CSR files to purchase SSL certificates.

3. Install the SSL certificate.

These steps are carefully designed to ensure transmission safety and prevent interception or illegal acquisition of certificates. The result is that the certificate you obtained in step two cannot be used on another server. If you need to do this, you must export the certificate in a different format.

For example, the practice of IIS is to generate a. pfx file that can be transferred and password-protected.

Passing this file to another server will allow you to continue using the original SSL certificate.

Misunderstanding three: HTTPS is too slow

Using HTTPS does not make your site faster (in fact, see below), but there are a few techniques that can significantly reduce the extra overhead.

First, compressing the text content reduces the CPU resources that are consumed by the decoding. For contemporary CPUs, however, this overhead is insignificant.

Second, an HTTPS connection is established, requiring additional TCP round-trip, so that some of the bytes sent and received are added. However, as you can see from the following figure, the new bytes are small.

When you first open a Web page, the HTTPS protocol is a little slower than the HTTP protocol because of the time it will take to read and verify the SSL certificate. Below is a waterfall diagram of the HTTP page opening time.

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

The part that establishes the connection, is about 10% slower. However, once an effective HTTPS connection is established and the page is refreshed, there is little difference between the two protocols. First the HTTP protocol refresh performance:

Then the HTTPS protocol:

Some users may find that HTTPS is a little faster than HTTP. This occurs in the internal LAN of some large companies, because the company's gateways typically intercept and analyze all network traffic. However, when it encounters an HTTPS connection, it can only be released directly, because HTTPS cannot be interpreted. Because of the lack of this interpretation process, HTTPS becomes faster.

Misconception two: It's safe to have Https,cookie and query strings.

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

For example, there used to be a British bank that uses sequential numbers to represent session IDs:

Hackers can register an account, find the cookie, and see how this value is represented. Then, change the cookie to hijack the other person's session ID. As for the query string, it can also be leaked in a similar way.

Misunderstanding one: Only sign up for the login page to require HTTPS

This is a common idea. It is thought that HTTPS protects the user's password and is not needed. Firefox browser new plugin Firesheep, proved that this idea is wrong. We can see that it's very easy to hijack other people's sessions on Twitter and Facebook.

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

1. This wifi is usually not encrypted, so it is easy to monitor all traffic.

2. WiFi usually uses NAT for extranet and intranet address translation, all intranet clients share an extranet address. This means that the hijacked session looks very much like the original logged-in person.

Twitter, for example, uses HTTPS for its landing page, but after logging in, other pages become HTTP. At this point, the session value in its cookie is exposed.

In other words, these cookies are created in an HTTPS environment, but are transmitted in an HTTP environment. If someone has hijacked these cookies, he will be able to speak on Twitter as you are.

Original: http://blog.httpwatch.com/2011/01/28/top-7-myths-about-https/
http://www.ruanyifeng.com/blog/2011/02/seven_myths_about_https.html: Ruan Yi Feng