Skip to main content

Web Services : Why HTTPS is required and How SSL/TLS works.

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.

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

Popular posts from this blog

Who is Peter Lynch and what is his philosophy in equity market investment? 25 Golden Rules of the most successful Fund Manager.

Peter Lynch (born January 19, 1944) is an American investor, mutual fund manager, and philanthropist. As the manager of the Magellan Fund at Fidelity Investments between 1977 and 1990, Lynch averaged a 29.2% annual return, consistently more than doubling the S&P 500 stock market index and making it the best-performing mutual fund in the world. During his 13 year tenure, assets under management increased from $18 million to $14 billion. He also co-authored a number of books and papers on investing and coined a number of well known mantras of modern individual investing strategies, such as Invest in what you know and ten bagger. Lynch is consistently described as a "legend" by the financial media for his performance record. Base on his career I have compiled his investing rules here. 25 GOLDEN RULES by @Peter Lynch 1: Nobody can predict interest rates, the future direction of the economy or the stock market. Dismiss all such forecasts & concentrate on what's actual

What is version checking in Hibernate ?

Version checking used in hibernate when more then one thread trying to access same data. For example : User A edit the row of the TABLE for update ( In the User Interface changing data This is user thinking time) and in the same time User B edit the same record for update and click the update. Then User A click the Update and update done. Change made by user B is gone. In hibernate you can prevent slate object updation using version checking. Check the version of the row when you are updating the row. Get the version of the row when you are fetching the row of the TABLE for update. On the time of updation just fetch the version number and match with your version number (on the time of fetching).

What are JEE Containers? What are their different types?

Containers are the interface between a component and the low-level, platform-specific functionality that supports the component. Before it can be executed, a web, enterprise bean, or application client component must be assembled into a Java EE module and deployed into its container. The assembly process involves specifying container settings for each component in the Java EE application and for the Java EE application itself. Container settings customize the underlying support provided by the Java EE server, including such services as security, transaction management, Java Naming and Directory Interface (JNDI) API lookups, and remote connectivity. Here are some of the highlights. The Java EE security model lets you configure a web component or enterprise bean so that system resources are accessed only by authorized users. The Java EE transaction model lets you specify relationships among methods that make up a single transaction so that all methods in one transaction are treated as a