We are using AES encryption to encrypt and decrypt data that is sent between browser and the server. AES encryption needs a secret key,which is hard coded and known by the client and the server.
Apart from the shared secret key, AES encryption also needs an initialisation vector( IV), which is unique and generated every time when a new request is sent either from the client or the server.
Is it ok for sharing this uniquely generated vector in every request in the http header between browser and server ? Are there any security risks in doing so?
Related
I'm trying to understand how internals of HTTPS works.
I understand that the server uses symmetric encryption using the pre-master key generated by the client and encrypted with the server's public key. My understanding is also that the server encrypts the hashes of resources rather than the actual resources, which the client will then decrypt and verify the hash. But I have two questions -
Is it correct to assume that the actual file is still sent by the server in plain text and that the browser trusts the contents only because it was able to hash the file and verify it with symmetric encryption?
How exactly is the information from the client, such as POST payload or URL parameters encrypted when sent to the server? Would the browser still hash the payload or the URL parameters or will it simply encrypt the data?
Thank you very much in advance for the help!
I understand that the server uses symmetric encryption using the pre-master key generated by the client and encrypted with the server's public key.
Only in some cipher suites. In general you should just regard the session key as securely negotiated by a key-agreement protocol and leave it at that.
My understanding is also that the server encrypts the hashes of resources rather than the actual resources, which the client will then decrypt and verify the hash.
I don't know what this means. The server has to return actual data, not just hashes. There are hashes used over the handshake and the SSL data messages, but that's no concern of yours: it is just part of the privacy SSL provides.
But I have two questions -
Is it correct to assume that the actual file is still sent by the server in plain text
No, of course not, it is encrypted with the session key. That's what the session key is for.
and that the browser trusts the contents only because it was able to hash the file and verify it with symmetric encryption?
No. Forget about hashing. Data is encrypted.
How exactly is the information from the client, such as POST payload or URL parameters encrypted when sent to the server?
With the session key.
Would the browser still hash the payload or the URL parameters
No. Forget about hashing.
or will it simply encrypt the data?
Yes.
Let's say we have a Server with a private and public key, the latter available to all Clients and we have a Client who doesn't have any asymmetrical keys of his own. We want to establish secure communication between the Server and the Client and the Client has to ensure Server's authenticity. This is a pretty common situation.
Now, it is my understanding that private/public key pair is usually used in such situations only to ensure authenticity (our Client can use the Server's public key to verify the Server's authenticity). To ensure two-sided communication between the Server and the Client Diffie–Hellman key exchange is used and the communication is then based on a shared secret key.
I can't stop by wonder why Diffie-Hellman is used at all in such situations. From what I understand Public-Key Cryptography could be used to both ensure authenticity AND to share a secret key between the Client and the Server. Server can send to Client a message encoded with its private key and Client can decode it using Server's public key to confirm its identity. Furthermore Client could use the Server's public key to send a new random secret key to the Server. Only Server would know this secret key as only Server knows his private key. I know some people advice not to use a public key to both encode and decode but nobody says why.
Obviously if both Client and Server had their own public/private keys they wouldn't even need to share any secret keys, but that's not a typical situation.
So... to sum it up. Why is Diffie-Hellman used instead of Secret Key Distribution with a Public-Key Cryptography? Any advantages?
I can't stop by wonder why Diffie-Hellman is used at all in such
situations. From what I understand Public-Key Cryptography could be
used to both ensure authenticity AND to share a secret key between the
Client and the Server.
Both Diffie-Hellman and RSA key exchange (where RSA is used for encryption) can be used with SSL/TLS. This depends on the cipher suite.
Server can send to Client a message encoded with its private key and
Client can decode it using Server's public key to confirm its
identity.
This is indeed what happens with DH key exchange with RSA or DSS authentication: the server signs its DH parameters using its private key, and the client can verify the signature.
Furthermore Client could use the Server's public key to send a new
random secret key to the Server. Only Server would know this secret
key as only Server knows his private key.
This is more or less what happens with RSA key exchange: the client encrypts the pre-master secret, which only the server can decipher.
You can read about all this in the Authentication and Key Exchange section of the TLS specification (leaving aside the anonymous key exchange). The choice of cipher suites (See Appendix A.5 and C), which depends on how the client and the server have been configured, will determine the key exchange mechanism used.
Fixed DH exchange is rather rare as far as I know. Ephemeral DH (DHE cipher suites) is more common. It can provider "Perfect Forward Secrecy": even if attackers get hold of the private key, they can't decipher existing traffic, since they would also need to have the DH parameters, which are not the same for all connections. However, this has a cost in terms of performance. You can find more on this topic in this article.
. Why is Diffie-Hellman used instead of Secret Key Distribution with a Public-Key Cryptography? Any advantages?
Ans: let's assume a hacker has been tracking the all messages exchanged between client and server and saving messages , but he can not decrypt those messages because he does not know the shared symmetric key. If private key of server is revealed then in case of diffie-hellman hacker still can not decrypt the messages because diffie Hellman algorithm never send the secret key on wire instead client and server agrees on same key without sharing, it's kind of key agreement algorithm not sharing. To attack diffie Hellman man in the middle should be live and should know server private key which was used for authentication. But in our case hacker has past diffie Hellman messages, so he can not use man in the middle attack. Meanwhile server changes it's private key so there is no damage. But if we use RSA keys to share secret key then on the disclosure of server's private key hacker can get all session symmetric secret keys and can decrypt all the past messages.
I was looking into SSL and some of the steps that are involved to set up an encrypted connection between a server and a client computer.
I understand that a server key and certificate is sent to the browser, and that a secret code is being calculated, like they say in the following video:
http://www.youtube.com/watch?v=iQsKdtjwtYI
around 5:22, they talk about a master secret code that is being calculated to start talking in an encrypted way.
My question now is: before the connection is actually encrypted (the handshake phase), all communication between the server and the client can be sniffed by a packet sniffer. Isn't it then possible to sniff the encryption key or other data that is used to set up a secure connection?
From the Wikipedia summary, I think the key part you're interested in is:
The client responds with a ClientKeyExchange message, which may
contain a PreMasterSecret, public key, or nothing. (Again, this
depends on the selected cipher.) This PreMasterSecret is encrypted
using the public key of the server certificate.
This is why the public key is so important. If you use the wrong public key, you're vulnerable to man in middle attacks.
Witness the justified worry whenever bogus SSL certificate issues (e.g. DigiNotar).
The secret key itself isn't transmitted at all, so it can't be sniffed. It is computed independently at both ends. The materials it is computed from is called a PreMasterSecret which is encrypted with the public key of the server certificate. So unless the server's private key has been compromised the secret key can be neither sniffed nor calculated independently.
If one way SSL is used (Server Certificate authentication) then data sent from client gets encrypted using Public key of the server certificate. So privacy protection is available for data sent from client. My questions are
Does this mean that in One way SSL data sent from Server to client is not encrypted and sent as plain text ?
For both server to client and client to server communications the data/message is not signed and so tamper protection or data integrity is not assured. Are there any other means to achieve data integrity while using SSL based transport security and not Message security options ?
One way SSL just means that the server does not validate the identity of the client. It has no effect on any of the other security properties of SSL.
While the SSL protocol is a bit complex, the basic gist of what happens is this: The client generates a random key, encrypts it so that only the server can decrypt it, and sends it to the server. The server and client now have a shared secret that can be used to encrypt and validate the communications in both directions.
The server has no idea of the client's identity, but otherwise, the encryption and message validation is two way.
Update:
1) Yes, encryption both ways is symmetric and uses a shared secret generated during session setup.
2) With a shared secret, message integrity is trivial to assure. You just ensure the message has a particular form. For example, I can prefix every message I send with a sequence number and append a checksum onto it before encryption. You decrypt it with the shared secret and validate the sequence number and checksum. How can an attacker substitute or modify the message without knowing the shared secret and still keep the sequence number and checksum intact?
In SSL, two things happen:
First, a session key is negotiated using something like the
Diffie-Hellman method. That generates a shared session key but never
transmits the key between parties.
Second, that session key is used in a normal symmetric encryption for
the duration of the connection.
SSL does use public/private in one way, because an X509 certificate is
used to identify at least one end of the connection. Those certs are
signed using an asymmetric key pair.
Extracted from How can SSL secure a two-way communication with only one key-pair?
This question already has answers here:
How does browser generate symmetric key during SSL handshake
(2 answers)
Closed 2 years ago.
I have been reading on HTTPS, trying to figure out how exactly it works. To me it doesn't seem to make sense, for example, I was reading this
https://ssl.trustwave.com/support/support-how-ssl-works.php
And notice it says this in the page
Step 4: xyz.com will next create a
unique hash and encrypt it using both
the customer's public key and
xyz.com's private key, and send this
back to the client.
Step 5: Customer's browser will decrypt the hash. This process shows
that the xyz.com sent the hash and
only the customer is able to read it.
What I don't understand is, couldn't a hacker just intercept the public key it sends back to the "customer's browser", and be able to decrypt anything the customer can?
Thanks for any response
Why is HTTPS required?
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 Jerry 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 Jerry.
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.
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.
can't get enough of web? behind the scenes when u type www.google.com in browser
What I don't understand is, couldn't a hacker just intercept the public key it sends back to the "customer's browser", and be able to decrypt anything the customer can.
First, understand that there are generally two steps of HTTPs communication.
1) Generate a shared symmetric key which can only be known between client and server, no one else knows it
2) With this shared symmetric key, client and server is able to safely communicate with each other without worrying about information being intercepted and decrypted by others.
So the question becomes, how can the client and server generate a secret shared key without being known by others in this open internet? This is the asymmetric algorithm coming to play, a demo flow is like below:
-- Client receives public key from server.
-- Client generates a key string "DummySharedKey" which will be later used as shared key, and encrypt it into "7$&^^%####LDD!!#" with server's public key, Man-in-the-middle may have the public key and might be able to intercept the encrypted data, but the data is useless to him as the data can only be decrypted by sever's private key.
-- Server receives the encrypted key string "7$&^^%####LDD!!#", and decrypt it into "DummySharedKey" with its private key
Above key exchange steps makes sure that only Client and Server can know the shared key is "DummySharedKey", no one else knows it.
So it's critical to understand that it is Client's responsibility to generate the shared key, NOT SERVER! (i think this is what confused you)
I also recommend you to take a look at this video which explains HTTPs very well.
https://www.youtube.com/watch?v=JCvPnwpWVUQ&list=FLt15cp4Q09BpKVUryBOg2hQ&index=3
What I don't understand is, couldn't a hacker just intercept the public key it sends back to the "customer's browser", and be able to decrypt anything the customer can.
Public/private key encryption is based on modulo arithmetics using prime numbers.
Such asymmetric encryption was only discovered in the mid-1970s. It is credited to Diffie and Hellman, and to Rivest, Shamir and Adleman. (Though, both actually rediscovered things already known by the British secret services.)
The wikipedia page on Diffie-Hellman has a detailed example of a secret key exchange through a public channel. While it does not describe SSL itself, it should be handy to make sense of why knowing a public key doesn't reveal the contents of a message.
You might also find this simple RSA example interesting.
I'm studying related topics and read several blogs like how-https-works and how-does-https-work-rsa-encryption-explained/.
I have summarized a sequence diagram based on my study and hope it can be helpful to someone who comes to this thread.
For more details, you can check the blog mentioned.
I have written a small blog post around SSL Handshake between the server/client. Please feel free to take a look.
SSL Handshake
A small snippet from the same is as follows:
"Client makes a request to the server over HTTPS. Server sends a copy of its SSL certificate + public key. After verifying the identity of the server with its local trusted CA store, client generates a secret session key, encrypts it using the server's public key and sends it. Server decrypts the secret session key using its private key and sends an acknowledgment to the client. Secure channel established."
It also describes the symmetric/asymmetric encryption which is used for SSL certificates and data transfer once secure transport is established.
For detailed explanation of SSL, see https://www.ietf.org/rfc/rfc2246.txt
Here are the brief ideas of SSL to answer your question:
1) Using certificates to authenticate. Server certificate is a must and client certificate is optional (only when the server requests it). A certificate is like something to prove who you are and it also contains a public key for asymmetric encryption.
2) Using asymmetric encryption (with public key in the server certificate) to establish a shared symmetric key which is used to transfer data between client and server securely by symmetric encryption (for performance reason because symmetric encryption is faster than asymmetric encryption).
The shared symmetric key is established by exchanging a premaster secret from client side (encrypted with server public key) and is derived from the pre-master secret together with client random and server random (thanks #EJP for pointing this out in the comment):
master_secret = PRF(pre_master_secret, "master secret",
ClientHello.random + ServerHello.random)
We need the server random and client random to prevent replay attacks that an attacker can capture the previous session and replay it for the new session.
What I don't understand is, couldn't a hacker just intercept the
public key it sends back to the "customer's browser", and be able to
decrypt anything the customer can.
The hacker cannot decrypt the message since he does not know the server private key. Be aware that public key cannot be used to decrypt the message.