I understand how a TLS connection can be secure once the shared secret can be used to encrypt the request/response, but how does TLS create the initial secure shared secret without being susceptible to man-in-the-middle attacks?
The basic idea is that there is some authentication to make sure that one is talking to the right party (typically done with certificates) and once one can be sure that it is the right peer the key exchange is done (typically Diffie Hellman). This whole handshake process is also protected against manipulation.
For the finer details please see How does SSL/TLS work?.
Related
I need to implement end-to-end encryption. To do this, I'm thinking of exchanging public keys between two users, then encrypt messages with the public key, and send the message back to the user via the server. Does it make sense to do this messaging over TLS, or would it be redundant? Since the data will be encrypted, I think TLS will be superfluous here, but I doubt it.
It's not only about encryption. You also need a trustful third party to authenticate the website in order to avoid DNS poisoning. That's the job of an SSL/TLS certificate.
For the purposes of secrecy and authenticity of communications I use SSL / TLS (https) with client certificate. If I log the entire SSL traffic on the server side, is the SSL log sufficient evidence that the communication between the server and the other side with client certificate was exactly as it is recorded in the log? At the beginning an asymmetric handshake is used but further communication continues with symmetric encryption. Symmetric encryption would not mind if one of the messages cannot be forged on the receiving side. As a server I know the symmetric key so it should be able for me to spoof one of the messages sent by the client, shouldn't it? What algorithm and what special settings shall I use, so that client could not say that he sent a different message than what I recorded in the log?
Logging anything (including data from SSL) does not proof the origin of the data. In theory you've could made up the data yourself. Even logging the complete SSL traffic including the necessary encryption key does not proof anything because in most cases this could have been made up too.
It might be acceptable as a proof if the whole SSL traffic is logged including the encryption key and if a client certificate was used for authentication (i.e. two-way SSL). The real client certificate owned by the client is a part you can not make up yourself. But there is still no guarantee that some judge would accept it as proof. And of course the client could try to deny that this is its own client certificate which was used.
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.
If I'm connecting to a mail server over SSL or TLS but using PLAIN authentication, is that secure?
Since the SSL/TLS connection is already encrypted, sending the password as PLAIN text doesn't hurt anything. You could encrypt the password as well, but then you're just double encrypting it. In most cases, I would consider that superfluous.
One case I can think of where you would use something other than PLAIN over SSL/TLS is if you choose to authenticate with certificates instead of passwords. Otherwise, I'd leave it at PLAIN.
Ryan is absolutely right if you are sure if you will never use your application without SSL. SSL is at the presentation layer and whenever a socket connection is established, SSL handshake is the first thing that happens which includes host verification, exchange of session keys and creating a secure transport layer. Communication at the application layer happens once this secure channel is established and the data that is exchanged is encrypted using the session keys and hence the communication is anyways secure.
However, if your application has an option to work with/without SSL then you should be encrypting your password separately. While working over SSL, this would be redundant but otherwise it is necessary.
I know that certificates that are sent by the server cant be faked (still there is MD5 collisions but costy) but what about faking the client ..
in man in the middle attack:
cant we tell the server that we are the legitimate client and take data from that server manipulate it then encrypt it again with legitimate client public key ? how does the client be sure that the data came really from the server ?
in theory .. can we inject any data into the response sent by the server to the client ?..
How are you authenticating the client? SSL client certificates? Or some application level system (cookies etc)?
Here's what SSL does in a nutshell:
Negotiates a Diffie-Hellman shared session key between the two parties
Has the server sign the session key and send the result to the client. Once the client verifies this, the client knows there is no MITM, and the server is who they say they are.
If client certificates are enabled, has the client sign the session key and send the signature to the server. The server now knows there is no MITM and the client is who they say they are.
Encrypts all data in both directions using the shared session key
Typically when you use SSL you won't use client certificates. Strictly speaking, the server does not know if the connection is MITM'd. However, most clients will disconnect if the server certificate is bad. The server assumes that if the client pushes forward with the connection, there is no MITM. Even if Mallory, doing the MITM, chooses not to propagate the disconnect from the client, he has no new information now; all he's done is connected to the server himself. Without intercepting the client's session cookie or other authentication information (which is only sent by the client after verifying the connection is secure) the MITM is useless.
So in short, as long as one end or the other verifies the certificate of the other end before initiating any high-level communication of sensitive information, SSL is secure in both directions.
You're right -- without secure certificate authentication on the client and server there is an opening for a man in the middle attack.
SSL can be "secure both ways" if you use mutual authentication also called two-way SSL.