HTTPS is now a must for every website : users want their information to be secure when they provide details; Chrome and Firefox explicitly mark as insecure sites that have pages that submit form but are not HTTPS; this is an SEO Ranking factor; in general, this has serious implications for user privacy. In fact, there are many ways to get an HTTPS certificate for free these days, so switching to HTTPS is just a matter of whether you want to or not.
Setting up HTTPS can be a bit intimidating to inexperienced users - it sounds complicated as it requires many steps, as well as specific knowledge of encryption and server configuration. . . . .
In this guide, I will explain the individual components and steps, and will clearly describe the various stages of the setup. I'll try to keep this guide simple and easy to understand, especially if your hosting provider also offers HTTPS certificates - you can do everything from the control panel quickly and easily.
I've included detailed instructions for owners of shared hosting plans in cPanel, Administrator of Apache HTTP Server, nginx on Linux and Unix, and Internet Information Server on Windows.
Let's swing the paddles and start from the basics~~~~
HTTP Vs. HTTPS Vs. HTTP/2 Vs. SSL vs. TLS: What is What?
Many acronyms are used to describe the communication process between client and server. These often make people who are not familiar with the principles look dizzy. . . . .
Hypertext Transfer Protocol (HTTP) is the basic communication protocol that enables clients and servers to communicate. It covers requests and responses, sessions, caching, authentication, and more. The coordination work, as well as work on the Hypertext Markup Language (HTML), began in 1989 and was developed by Sir Tim Berners-Lee and his team at CERN. The first official version of the protocol (HTTP 1.0) was released in 1996, shortly followed by the currently widely adopted version (HTTP 1.1) released in 1997.
This protocol transmits information in clear text between the browser and the server, allowing the network through which the information travels to view the transmitted information. This is a security hazard, so HTTP Secure (HTTPS) was introduced , allowing the client and server to first establish an encrypted communication channel and then pass plaintext HTTP messages through it, effectively protecting them from it.
Create an encrypted channel using the Transport Layer Security (TLS) protocol , formerly known as Secure Sockets Layer (SSL). The terms SSL and TLS are often used interchangeably, with SSL 3.0 being replaced by TLS 1.0. SSL is a protocol developed by Netscape, while TLS is an IETF standard. As of this writing, all versions of SSL (1.0, 2.0, 3.0) are obsolete due to various security issues and will produce warnings in current browsers, and TLS versions (1.0, 1.1, 1.2) are in use, currently there are 1.3 drafts.
So, sometime in 1996 and 1997, we got the current stable version of the internet (HTTP 1.1, with or without SSL and TLS) that still supports most websites. Previously, HTTP was used for non-sensitive traffic (such as reading news), and HTTPS was used for sensitive traffic (such as authentication and e-commerce); however, with the increasing focus on privacy, web browsers (such as Google Chrome) will use HTTP for Websites are marked as "not private" and HTTP warnings will be introduced in the future.
An upgraded version of the HTTP protocol that is being adopted by more and more websites - HTTP/2 adds new features (compression, multiplexing, prioritization) to reduce latency and improve performance and security.
In HTTP version 1.1, a secure connection was optional (you might have HTTP and/or HTTPS independent of each other), while in HTTP/2 it was actually required - even though the standard defines HTTP/2 (with or without TLS), most browser vendors say they will only implement HTTP/2 support over TLS.
What does HTTPS offer?
Why use HTTPS in the first place? It has three main reasons:
confidentiality
Protect the communication between the two parties in public media such as the Internet. For example, without HTTPS, when a user using the access point is shopping online, the person running the Wi-Fi access point may see private information such as credit cards.
Integrity
This ensures that the information arrives at its destination intact and unchanged. For example, our Wi-Fi friends can add extra advertisements to our website, reduce the quality of images to save bandwidth or change the content of the articles we read. HTTPS ensures that the website cannot be modified.
Certification
This ensures site consistency. For example, the same person running a Wi-Fi access point could send a browser to a fake website. HTTPS ensures that a website that says it's example.com is example.com. Some certificates even check the legal identity behind the website, so you can rest assured that yourbank.com is the website of YourBank, Inc.
Cryptography
Confidentiality, integrity and authentication are not specific to HTTPS: they are core concepts of cryptography. Let's look at them again.
keep secret
Confidentiality is privacy, i.e. protecting information from reading by unauthorized third parties. The process typically involves converting the readable (ie audible and visible) form of the plaintext information into a ciphertext , unreadable version. This process is called encryption . The reverse process of turning unreadable ciphertext back into readable plaintext is called decryption . There are many ways - cryptographic functions (or algorithms ) - to encrypt and decrypt information.
In order for both parties to be able to communicate, they should agree on two things:
- which algorithm (cryptographic function) they will use in their communication
- Which parameters, passwords or rules (i.e. secrets ) will be used in the method.
There are two main types of encryption:
- symmetry
Both parties share a common secret key .
- asymmetrical
A party has a pair of secret and public key, the basis of public key infrastructure (PKI).
The methods of the symmetric class rely on two parties having a shared key, the sender uses the same method and key to encrypt the message, and the receiver uses the same method and key to decrypt (see figure below). The problem with these methods is how the two parties negotiate (ie exchange) secrets with each other but without requiring the two parties to be physically connected, the two parties need to have a secure channel of communication.
These kinds of problems are solved in an asymmetric way - based on public and private keys. The plaintext is encrypted with one of the keys and can only be decrypted with the other complementary key.
So how does it work? Let's assume we have two parties willing to communicate with each other - Alice and Bob (these are the names of fictional characters in some tutorials and safety manuals, so we'll stick to the tradition here too). They all have a pair of keys: a private key and a public key. Private keys are only known to their respective owners; anyone can use the public key.
If Alice wanted to message Bob, she would get his public key, encrypt the plaintext and send him the ciphertext. He would then decrypt it using his private key.
If Bob wants to send a reply to Alice, he will get the public key, encrypt the plaintext and send the ciphertext. Alice will then decrypt it using her private key.
For more click here: http://igeekbar.com/igeekbar/post/229.htm
When to use symmetric and when to use asymmetric encryption? Asymmetric encryption is used to exchange secrets between client and server . In real life, we usually don't need two-way asymmetric communication - if one of the parties (let's just call it the server , for simplicity) has a set of keys, so it can receive an encrypted message. It truly secures information in only one direction - from client to server, because information encrypted with the public key can only be decrypted using the private key; therefore, only the server can decrypt it. The other direction is unprotected - information encrypted with the server's private key can be decrypted by anyone's public key.