41

I want to know how HTTPS is implemented. Whether the data is encrypted or path is encrypted (through which data is passed). I will be thankful if someone provides me implementation details.

johnnyRose
  • 7,310
  • 17
  • 40
  • 61
Jagan
  • 4,649
  • 19
  • 60
  • 70

5 Answers5

85

Very simply, HTTPS uses Secure Socket Layer to encrypt data that is transferred between client and server. SSL uses the RSA algorithm https://en.wikipedia.org/wiki/RSA_(cryptosystem), an asymmetric encryption technology. The precise details of how the algorithm works is complex, but basically it leverages the fact that whilst multiplying two large prime numbers together is easy, factoring the result back into the constituent primes is very, very hard. How all SSL/RSA encryption works is:

The server generates two large prime numbers, and multiplies them together. This is called the "public key". This key is made available to any client which wishes to transmit data securely to the server. The client uses this "public key" to encrypt data it wishes to send. Now because this is an asymmetric algorithm, the public key cannot be used to decrypt the transmitted data, only encrypt it. In order to decrypt, you need the original prime numbers, and only the server has these (the "private key"). On receiving the encrypted data, the server uses its private key to decrypt the transmission.

In the case of you browsing the web, your browser gives the server its public key. The server uses this key to encrypt data to be sent to your browser, which then uses its private key to decrypt.

So yes all data transmitted to/from server over HTTPs is encrypted - and encrypted well. Typical SSL implementations use 128 or 256 digits for their keys. To break this you need a truly vast amount of computing resources.

As far as I am aware the request for a server asset is not encrypted - use httpfox https://addons.mozilla.org/en-US/firefox/addon/6647/ or Wireshark http://www.wireshark.org/ or something to confirm.

AtomHeartFather
  • 954
  • 17
  • 35
Richard H
  • 38,037
  • 37
  • 111
  • 138
  • 15
    There are some mistakes in your answer. The public key is typically 2048 bits long and it is only used to exchange a key for a symmetric cipher e.g. RC4. The reason is that a symmetric cipher is much more secure for a given key length and also encryption and decryption is much faster. All the actual data passing over the link is then encrypted with the symmetric key. – JeremyP Oct 19 '10 at 13:37
  • 1
    @JeremyP - was assuming 1 byte per digit which is 1024 or 2048 bits. And you are of course correct about RSA being used only to exchange keys with symmetric algorithm being used to encrypt data. – Richard H Oct 19 '10 at 14:05
  • 5
    One byte per digit does not make sense (except in base 256). An RSA key is literally a single 1024 bit or 2048 bit binary number. – JeremyP Oct 19 '10 at 14:23
  • 2
    By the way, SSL is transport layer encryption. Everything that is transmitted across the TCP connection after the client gets the public key is encrypted. That includes the first line of the HTTP request containing the server resource asked for. – JeremyP Oct 19 '10 at 14:27
  • There are errors in this accepted answer and it has not aged well. Modern implementation should use TLS not SSL. Both TLS and SSL support multiple asymmetric cyphers. Data is encrypted in both directions. The signature on the public key (public key + metadata + signature = certificate) proves the ientity of the server as well as providing confidentiality. – symcbean Jun 12 '17 at 16:27
  • @symcbean : correct me if am wrong, lets suppose I have a set up proxy and I have the public key of the certificate then I can see all data send from server? – Bytecode Aug 01 '18 at 09:20
  • 2
    @Bytecode: Nope - because the data is not encrypted using the public key - this is used to negotiate a symmetric key and because half of that negotiation originates from the client it can't be decrypted using the server's public key. Subsequetly data is encrypted using the ephemeral, symmetric key, the server's public cert is of no use. – symcbean Aug 01 '18 at 11:41
  • data send from the server is encrypted with private key and I can decrypt the same using public key at proxy? – Bytecode Aug 01 '18 at 18:28
  • here is a python library that does it. https://pycryptodome.readthedocs.io/en/latest/src/examples.html#generate-public-key-and-private-key ..... – Joey Gough Sep 13 '18 at 23:45
  • 1
    @Bytecode Any message transmitted through internet is encrypted by public key and decrypted by private key. Data from the server is encrypted by `client public key` while to server by `server public key`. The insight here is a third party can intercept the public key and message but without private key they can't get the plain text. – hashtabe_0 Aug 19 '19 at 09:22
  • Based on your answer, is it possible to brute force the public key? @hashtabe_0 – P.Coder Jan 31 '20 at 04:31
  • @P.Coder The short answer is yes. For example, [RSA numbers](https://en.wikipedia.org/wiki/RSA_numbers) like RSA-155(512 bits), RSA-768(768 bits) were factored. – hashtabe_0 Feb 10 '20 at 10:31
  • so if server only has the private key and decrypts using the key, how does the client(user) decrypt it owning only the public key ? @RichardH – Ahmed Can Unbay Aug 10 '20 at 19:18
11

In two ways.

  1. By ensuring that all information transmitted between you and the website is encrypted. It does this via a key-exchange process using RSA (which exchanges a 'session key', which is used for the actual encryption).

  2. By (trying to) demonstrate trust in the website you visit. Certificates are provided to domains, and the idea is that on your machine you trust only certificates from various reputable sources. Then, you can (in theory) be assured that when a certificate pops up for "Your Bank", it is really "Your Bank" website, and not some other website. In practice, very few people care/notice this aspect of SSL.

It's transport layer security. It is not application level. You still need to follow secure coding practices and various other techniques to ensure that your site is secure.

Noon Silk
  • 54,084
  • 6
  • 88
  • 105
9

I thought this was a really concise human readable explanation: http://robertheaton.com/2014/03/27/how-does-https-actually-work/

Here is my summarised version:

Concepts:

  • Asymmetric cryptography algorithm – Public key encryption, private key decryption.
  • Symmetric cryptography algorithm – Public key encryption and decryption.

Handshake:

  1. Hello – Client send cryptography algorithm and the SSL version it supports.
  2. Certificate Exchange – Server sends certificate to identify itself, and certificate public key.
  3. Key Exchange – The client uses Certificate public key to encrypt a new client regenerated public key (using the agreed asymmetric cryptography algorithm from step 1) and sends it to the server. The server decrypts it using its private key (using asymmetric cryptography algorithm).
  4. Data Exchange - This public key is now know by both client and server. It is used for subsequent requests/responses for both encryption and decryption on both client and server (symmetric cryptography algorithm)
AntonK
  • 2,303
  • 1
  • 20
  • 26
6

You can read all the details in the TLSv1 RFC-2246.

For security analysis, specifically the following section:

F. Security analysis

The TLS protocol is designed to establish a secure connection between a client and a server communicating over an insecure channel. This document makes several traditional assumptions, including that attackers have substantial computational resources and cannot obtain secret information from sources outside the protocol. Attackers are assumed to have the ability to capture, modify, delete, replay, and otherwise tamper with messages sent over the communication channel. This appendix outlines how TLS has been designed to resist a variety of attacks.

further content snipped

Community
  • 1
  • 1
Klaus Byskov Pedersen
  • 117,245
  • 29
  • 183
  • 222
0

Server and client do not have control over the path that is used to transmit the data. The path used is a matter for the network layer (Internet Protocol - IP), not for the Transport Layer Security (TLS)

The data itself is encrypted, and there are also means for checking server autenticity, as mentioned by Noon Silk.

http://en.wikipedia.org/wiki/Transport_Layer_Security

Leandro Gomide
  • 998
  • 1
  • 10
  • 31