I want to decrypt https stream in my https server. I have succeeded in decrypting it which used RSA secret exchange when i have private key. But I dont know how to descryt it when it uses DHE for secret exchange because I dont have any parameters.how to get Diffie–Hellman key exchange parameters?
This should not be possible. The whole idea behind forward secrecy is that you use Diffie-Hellman key exchange because this way a captured session cannot be decrypted later, even if an attacker gets access to the private key of the certificate.
The "E" in DHE is for ephemeral. It means transient, fleeting, or temporary. The key material that you need to decrypt the conversation is not permanently stored anywhere. It's generated for a single TLS session and then discarded, ensuring that no one, even the original parties, can retroactively decrypt the conversation.
Related
I have a basic understanding that HTTPS creates a secure connection between a user and a server using some sort of unique identifying code. However, if the server sends this code (or whatever it is) to the user, can't that code be intercepted and that renders the entire HTTPS just as vulnerable as HTTP?
I'm a total newbie to this area, and am interested in how it works. The current answers on Stack Overflow don't give me the full answer.
I'm not sure it's fair to say there isn't any answer on Stack Overflow to the question of how SSL works:
https://stackoverflow.com/search?q=how+does+ssl+work
Cookies work the same way over HTTPS that they do over HTTP. HTTPS is just HTTP, but with the server and client using a "shared secret" symmetric encryption key to encrypt and decrypt the data they exchange so that a third party can't intercept and read the communication.
So having said that, and largely agreeing with the advice to start reading at Wikipedia, why don't I take a quick stab at doing this a modest disservice by explaining it as briefly as I know how.
First, "SSL" is now officially obsolete since the POODLE exploit in SSLv3 will never be fixed. SSL (Secure Sockets Layer) has been succeeded by TLS (Transport Layer Security) and has really become a generic although somewhat inaccurate term referring to secure HTTP (HTTPS).
Still, SSL and TLS both use the same underlying technologies and general ideas.
There are several technologies involved, all of them complicated, and the interplay between them is complicated.
But here are the high points, jammed into a little nutshell.
SSL/TLS fundamentally relies on public/private key asymmetric encryption, in order to securely exchange a shared secret--an ephemeral (disposable, short-lived) symmetric encryption key known only to the server and the client, which the client and server then use to encrypt the messages they exchange from that point forward.
Asymmetric encryption is a big, quite sciencey topic all by itself.
a·sym·me·try
āˈsimətrē/
noun: lack of equality or equivalence between parts or aspects of something; lack of symmetry.
Assymetric encryption utilizes paired private and public keys which are derived mathematically from very large, mathematically related prime numbers.
The encryption is asymmetric because if a message is encrypted with the "private" key, it can only be decrypted by the "public" key, and vice-versa.
It is therefore absolutely critical to keep the private key private. The public key can be (indeed is) published to the world
TLS uses asymmetric encryption and a handshake protocol to create and exchange a symmetric session encryption key that is known only to the server and the client.
Asymmetric encryption is an order of magnitude slower than symmetric encryption, making it unsuitable for encrypting data for real-time communication. The other thing making it unsuitable for encrypting data for two-way communication is that anything encrypted with the server's private key can be decrypted by anybody who has possession of the public key. By definition, that's everybody.
So, committing an atrocious act of willful oversimplification; the handshake protocol basically allows the client to send an encrypted challenge that only the server can decrypt, the server can then sign that challenge with its private key and return it. The client knows both which challenge it sent, and how to verify the server's signature using the server's public key. Once the client and the server are satisfied that their communication has not been tampered with, they can securely exchange an ephemeral symmetric encryption key. Some steps may be combined to reduce the number of round trips, and different versions of the protocol, you know, differ somewhat in the details... (willfully oversimplified, remember).
There are a number of encryption protocols and key lengths that can be used, and these specifics are negotiated during the key exchange. Let's just say the client and server agree to AES encryption with a 256 bit key.
So, once the client and server have securely exchanged that 256 bit key (the size of which they negotiated), they can encrypt and exchange data securely at will using that key with the AES algorithm that they also negotiated. No other party has that ephemeral encryption key, thus no other party can decrypt the data they exchange.
Symmetric encryption is much, much faster than asymmetric encryption. As such, the performance impact of encrypting/decrypting large data transfers is virtually irrelevant.
The expensive part of HTTPS is in the initial protocol handshake and key exchange since it requires multiple round trips and a couple of rounds of super expensive asymmetric encryption. Because of this, HTTPS communication benefits enormously when the client and server reuse the same connection for multiple requests. For information on that, look into the SPDY protocol.
Finally, you should research forward secrecy and/or perfect forward secrecy. What forward secrecy does is to exchange an ephemeral public/private keypair during the handshake, then use that ephemeral public/private key pair to handshake and exchange a private symmetric key and quickly discard the ephemeral private/public keypair. What this accomplishes is protection against replay and decryption of a captured HTTPS session in the future if the web server's private key is compromised.
There are protocols that allow two parties to arrive at a shared encryption key, even though all communication between them is in the clear.
Check out the Wikipedia article on how this happens during the SSL handshake.
After they have this session key, this is used to encrypt the payload messages.
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.
Isn't it possible to simply capture the key while it's being negotiated between machines?
Let's say I connect to my bank's website. Browser will send request to bank server. Bank server will send me copy of its SSL certificate. If it's valid, browser will send signed ack. Isn't it possible to simply capture private key at that time?
Your private key (and bank's too) is never sent over the network. The bank's public key is a part of the X509 certificate that it sends to your browser. If banks signs anything it does it using its private key, and your browser verifies the signature using the bank's public key (from the certificate). The whole SSL session is encrypted using symmetric cipher (for performance reasons). To be able to do that both parties need to exchange the session key (different for each connection and renegotiated after defined interval of time). This exchange is done using Diffie-Hellman algorithm. During this exchange the key is not sent over the network, it is computed independently by both parties.
Isn't it possible to simply capture the key while it's being
negotiated between machines?
No because it is never sent, it is computed independently. You would need the server's private key, which is private, to repeat the independent computations that lead to the session key. So it is secure.
Only public key is shared. The bank dosen't need to share the private one.
Private key is not shared and is not stored in the cert.
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?