Why is HTTPS required?
Hyper Text Transfer Protocol Secure (HTTPS) is the secure version of HTTP, the protocol over which data is sent between your browser and the website that you are connected to. The 'S' at the end of HTTPS stands for 'Secure'. It means all communications between your browser and the website are encrypted. HTTPS is often used to protect highly confidential online transactions like online banking and online shopping order forms.Web browsers such as Internet Explorer, Firefox and Chrome also display a padlock icon in the address bar to visually indicate that a HTTPS connection is in effect.
To verify whether the website is authenticated/certified or not (uncertified websites can do evil things). An authenticated website has a unique personal certificate purchased from one of the CA’s.
Public keys are keys which can be shared with others. Private keys are meant to be kept private.
Suppose Mr.X generates a private key and public key. He makes many copies of that public key and shares with others.
Now, others can only encrypt the data using the public key and that data can only be decrypted by the private key of Mr.X.
Another approach is to use public keys to only decrypt the data and private keys to only encrypt the data.
CA then creates a personal certificate based on CSR including domain name, owner name, expiry date, serial no. etc and also adds an encrypted text (= digital signature) to the certificate and finally encrypts the whole certificate with the public key of the server and sends it back to the website owner.
This certificate is then decrypted with the private key of the website owner and finally, he installs it on the website.
Note: That encrypted text is the digital signature of the CA. That text is encrypted by the private key of the CA and can only be decrypted by a public key of CA.
When you install your operating system or Browser, root-certificates from many trusted CA's like GeoTrust, VeriSign, GoDaddy etc. come with it. These root-certificates contain the public key of that CA provider which helps decrypt the signature.
†The Server Name Identification (SNI) standard means that the hostname may not be encrypted if you're using TLS. Also, whether you're using SNI or not, the TCP and IP headers are never encrypted. (If they were, your packets would not be routable.)
HTTPS security can be split into 2 parts (Handshakes):
1. To validate the certificate of a website:
1) When you enter the URL www.Google.com, Google’s server gives its public key and certificate (which was signed by GeoTrust) to the Browser.
2) Now browser has to verify the authenticity of the certificate i.e. it’s actually signed from GeoTrust or not. As browsers come with a pre-installed list of public keys from all the major CA’s, it picks the public key of the GeoTrust and tries to decrypt the digital signature of the certificate which was encrypted by the private key of GeoTrust.
3) If it’s able to decrypt the signature (which means it’s a trustworthy website) then it proceeds to the next step else it stops and shows a red cross before the URL.
2. To create a secure connection (encrypts outgoing and incoming data) so that no one else can read it:
1) As I mentioned, Google sends its public key when you enter www.Google.com . Any data encrypted with this public key can only be decrypted by Google’s private key which Google doesn’t share with anyone.
2) After validating the certificate, browser creates a new key let’s call it Session Key and make 2 copies of it. These keys can encrypt as well as decrypt the data.
3) The browser then encrypts (1 copy of session key + other request data) with the Google's public key . Then it sends it back to the Google server.
4) Google’s server decrypts the encrypted data using its private key and gets the session key , and other request data.
Now, see, server and browser both have got the same copies of session key of the browser. No one else has this key, therefore, only server and browser can encrypt and decrypt the data. This key will now be used for both to decrypt and to encrypt the data.
5) When Google sends the data like requested HTML document and other HTTP data to the browser it first encrypts the data with this session key and browser decrypts the data with the other copy of the session key.
6) Similarly, when browser sends the data to the Google server it encrypts it with the session key which server decrypts on the other side.
Note: This session key is only used for that session only. If the user closes the website and opens again, a new session key would be created.
1. Client Hello
Information that the server needs to communicate with the client using SSL. This includes the SSL version number, cipher settings, session-specific data.
2. Server Hello
Information that the server needs to communicate with the client using SSL. This includes the SSL version number, cipher settings, session-specific data.
3. Authentication and Pre-Master Secret
Client authenticates the server certificate. (e.g. Common Name / Date / Issuer) Client (depending on the cipher) creates the pre-master secret for the session, Encrypts with the server's public key and sends the encrypted pre-master secret to the server.
4. Decryption and Master Secret
Server uses its private key to decrypt the pre-master secret. Both Server and Client perform steps to generate the master secret with the agreed cipher
5. Encryption with Session Key
Both client and server exchange messages to inform that future messages will be encrypted.
REFERENCES :
1. https://stackoverflow.com/questions/6241991/how-exactly-https-ssl-works
2. https://stackoverflow.com/questions/499591/are-https-urls-encrypted?rq=1
3. https://stackoverflow.com/questions/187655/are-https-headers-encrypted?noredirect=1&lq=1
4. https://www.youtube.com/watch?v=iQsKdtjwtYI
Who are CA’s (Certificate Authorities)?
CA’s are globally trusted companies like GoDaddy, GeoTrust, VeriSign etc who provide digital certificates to the websites.What are public keys and private keys?
Keys are nothing but long random numbers used to encrypt/decrypt data.Public keys are keys which can be shared with others. Private keys are meant to be kept private.
Suppose Mr.X generates a private key and public key. He makes many copies of that public key and shares with others.
Now, others can only encrypt the data using the public key and that data can only be decrypted by the private key of Mr.X.
Another approach is to use public keys to only decrypt the data and private keys to only encrypt the data.
How does a company get a certificate?
Website owner first generates a public key and private key, keeping the private key secret. He gives a Certificate Signing Request file (CSR) and his public key to the CA.CA then creates a personal certificate based on CSR including domain name, owner name, expiry date, serial no. etc and also adds an encrypted text (= digital signature) to the certificate and finally encrypts the whole certificate with the public key of the server and sends it back to the website owner.
This certificate is then decrypted with the private key of the website owner and finally, he installs it on the website.
Note: That encrypted text is the digital signature of the CA. That text is encrypted by the private key of the CA and can only be decrypted by a public key of CA.
When you install your operating system or Browser, root-certificates from many trusted CA's like GeoTrust, VeriSign, GoDaddy etc. come with it. These root-certificates contain the public key of that CA provider which helps decrypt the signature.
Are HTTPS URLs encrypted?
Yes, the SSL connection is between the TCP layer and the HTTP layer. The client and server first establish a secure encrypted TCP connection (via the SSL/TLS protocol) and then the client will send the HTTP request (GET, POST, DELETE...) over that encrypted TCP connection.Are HTTPS headers encrypted?
The whole lot is encrypted† - all the headers. That's why SSL on vhosts doesn't work too well - you need a dedicated IP address because the Host header is encrypted.†The Server Name Identification (SNI) standard means that the hostname may not be encrypted if you're using TLS. Also, whether you're using SNI or not, the TCP and IP headers are never encrypted. (If they were, your packets would not be routable.)
HTTPS security can be split into 2 parts (Handshakes):
1. To validate the certificate of a website:
1) When you enter the URL www.Google.com, Google’s server gives its public key and certificate (which was signed by GeoTrust) to the Browser.
2) Now browser has to verify the authenticity of the certificate i.e. it’s actually signed from GeoTrust or not. As browsers come with a pre-installed list of public keys from all the major CA’s, it picks the public key of the GeoTrust and tries to decrypt the digital signature of the certificate which was encrypted by the private key of GeoTrust.
3) If it’s able to decrypt the signature (which means it’s a trustworthy website) then it proceeds to the next step else it stops and shows a red cross before the URL.
2. To create a secure connection (encrypts outgoing and incoming data) so that no one else can read it:
1) As I mentioned, Google sends its public key when you enter www.Google.com . Any data encrypted with this public key can only be decrypted by Google’s private key which Google doesn’t share with anyone.
2) After validating the certificate, browser creates a new key let’s call it Session Key and make 2 copies of it. These keys can encrypt as well as decrypt the data.
3) The browser then encrypts (1 copy of session key + other request data) with the Google's public key . Then it sends it back to the Google server.
4) Google’s server decrypts the encrypted data using its private key and gets the session key , and other request data.
Now, see, server and browser both have got the same copies of session key of the browser. No one else has this key, therefore, only server and browser can encrypt and decrypt the data. This key will now be used for both to decrypt and to encrypt the data.
5) When Google sends the data like requested HTML document and other HTTP data to the browser it first encrypts the data with this session key and browser decrypts the data with the other copy of the session key.
6) Similarly, when browser sends the data to the Google server it encrypts it with the session key which server decrypts on the other side.
Note: This session key is only used for that session only. If the user closes the website and opens again, a new session key would be created.
The Standard SSL Handshake
The following is a standard SSL handshake when RSA key exchange algorithm is used:1. Client Hello
Information that the server needs to communicate with the client using SSL. This includes the SSL version number, cipher settings, session-specific data.
2. Server Hello
Information that the server needs to communicate with the client using SSL. This includes the SSL version number, cipher settings, session-specific data.
3. Authentication and Pre-Master Secret
Client authenticates the server certificate. (e.g. Common Name / Date / Issuer) Client (depending on the cipher) creates the pre-master secret for the session, Encrypts with the server's public key and sends the encrypted pre-master secret to the server.
4. Decryption and Master Secret
Server uses its private key to decrypt the pre-master secret. Both Server and Client perform steps to generate the master secret with the agreed cipher
5. Encryption with Session Key
Both client and server exchange messages to inform that future messages will be encrypted.
REFERENCES :
1. https://stackoverflow.com/questions/6241991/how-exactly-https-ssl-works
2. https://stackoverflow.com/questions/499591/are-https-urls-encrypted?rq=1
3. https://stackoverflow.com/questions/187655/are-https-headers-encrypted?noredirect=1&lq=1
4. https://www.youtube.com/watch?v=iQsKdtjwtYI
Comments
Post a Comment