How secure is HTTPS than HTTP


HTTPS or HTTP Secure is the use of HTTP in connection with encryption and authentication. Usually only the requested web server has to authenticate itself with a certificate.

An encrypted connection with a browser is signaled with "https: //" (TCP port 443) instead of "http: //" (TCP port 80). The web server must authenticate itself to the client as to whether it is actually the web server that is located at the address entered. In addition, the connection or session is encrypted end-to-end. This means that the stations between client and server cannot decrypt the communication.

SSL / TLS is responsible for authentication and encryption. It sits between HTTP and the transport protocol TCP. This means that SSL / TLS is also available for other application protocols. For example SMTPS, IMAPS and FTPS. SSL works almost invisibly for the user.
SSL was developed by Netscape up to version 3.0 and then transferred to TLS by the IETF. Although TLS is used throughout today, people still like to talk about SSL.

How does HTTPS work?

The following illustration and description of the HTTPS authentication process with SSL / TLS is simplified for a better understanding.

The connection is established via an HTTPS request from the client to the server. The client is, for example, a web browser. The server would therefore be a web server.

  1. Client Hello: The client contacts the server using a protocol with encryption options.
  2. Server Hello, Certificate, Server Key Exchange, Server Hello Done: The server accepts the connection and sends its certificate with the public key of its key pair to the client for authentication.
  3. The client checks the server certificate and its validity (validation). If the client recognizes the certificate as invalid, the connection is terminated at this point.
  4. If the client recognizes the certificate as valid, the client generates the symmetric session key.
  5. Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message: The client uses the server's public key to encrypt the session key and sends it to the server.
  6. The server can use its private key to decrypt the encrypted session key.
  7. Encrypted Handshake Message, Change Cipher Spec, Encrypted Handshake Message: The server confirms the secret session key.
  8. All HTTP requests and responses are then encrypted until the connection is cleared down.

Session key

The session key for encrypting the actual data or communication is either transmitted asymmetrically encrypted or, alternatively, generated on both sides using the Diffie-Hellman process.

Consistent encryption with HTTPS

Internet security experts state that HTTP connections should generally be encrypted. General and non-optional encryption is required for HTTP / 2. Here you can of course ask yourself why the retrieval of information on the Internet should be encrypted. You can understand that with online shopping and online banking. This is about the transfer of personal data and payment instructions. We have learned that these connections are worth protecting.

But what about, for example, with the retrieval of this website? Why should that be encrypted?

Let's assume that a journalist finds out about the encryption options for e-mails with GnuPG and the anonymization options offered by Tor. If this exchange of information is intercepted and the journalist identified, then a central point could come up with the idea that the journalist is in contact with a whistleblower. Then you will monitor more intensively and try to slip a Trojan horse on him. If his HTTP connections had been encrypted, nobody would have known about his need for information.

The general encryption makes sense because one has to assume that the normal Internet user does not know what he is doing and what he is doing and the consequences. Most internet users are unable to decide when they need encryption and when it is not. This is why general encryption of Internet connections is required.

How secure is HTTPS?

Whether an SSL connection with HTTPS is secure or not mainly determines the behavior of the client when checking the SSL certificate of the server. The client must check whether the certificate presented by the server belongs to it and whether it is still valid. To do this, the client uses OCSP (Online Certificate Status Protocol) to inquire with the responsible certification authority (CA). This process is called validation.

However, the implementation of OCSP in the browser is generally defective. If the browser does not receive a response from the certification authority after a certain period of time, then it must accept the certificate without being checked. This means that if an attacker is able to hinder the validation in any way, he can manipulate the establishment of the connection and, for example, as man-in-the-middle, lock into the connection between client and server despite encryption.
Another sticking point that every encrypted connection brings with it is when the session key is transmitted. Or when the secret key becomes known, which means that the session key can be inferred and recorded, encrypted transmissions can subsequently be decrypted. With PFS in combination with Diffie-Hellman you can make HTTPS or SSL / TLS even more secure. Nevertheless, the problem still remains with the acceptance of certificates that are still accepted because of an unreachable or compromised certification authority.

Overview: HTTP

Overview: SSL / TLS

Other related topics:


Product recommendations

Everything you need to know about networks.

Network technology primer

The network technology primer is a book about the basics of network technology, transmission technology, TCP / IP, services, applications and network security.

I want that!

Everything you need to know about networks.

Network technology primer

The network technology primer is a book about the basics of network technology, transmission technology, TCP / IP, services, applications and network security.

I want that!