In emacs/wanderlust, if one selects the 'clear' method of password transmission, but enables SSL for IMAP, is the password transmission secured by SSL encryption? Specifically, concern arises from the following para in the wanderlust Info manual:
There are two ways to use SSL. One is to start SSL negotiation just
after the connection establishment (generic way). The other one is to
start SSL negotiation by invoking STARTTLS command in the each session.
So is password transmission done before or after SSL encryption in the first method? If before, then does the second (STARTTLS based) method ensure encrypted password transmission?
The password is secure in either case.
The difference between these methods is in another aspect: The first method starts a TLS connection right after the TCP handshake, and before any IMAP exchange starts. Hence, it uses a different port than regular IMAP, but can be used with IMAP servers that do not have built-in TLS support, by simply tunneling their traffic.
With the second method however, the client connects to the regular IMAP port and starts an unencrypted IMAP exchange. However, before sending any credentials or any other private data it tells the server to upgrade the connection to a TLS connection, and only resumes the IMAP exchange (including password transfer) after this upgrade succeeded. This method allows to serve encrypted IMAP from the default IMAP port, but needs an IMAP server that can handle this IMAP protocol extension.
Nowadays, most servers support STARTTLS, so both methods are mostly equivalent. Use whatever Wanderlust uses as default.
Related
From my understanding, each browser implement tls/ssl themself, which mean when user open a https website from a browser, the browser is responsible for encrypt the request.
So is it possible to make a browser or any other type of client that doesn't implement tls/ssl and therefore will make https without encryption? And if yes, then how ?
... client that doesn't implement tls/ssl and therefore will make https without encryption?
HTTPS is HTTP inside a TLS connection. This means a client which does not implement SSL/TLS will not be able to make a HTTPS connection in the first place by the very definition of what HTTPS is.
It might in theory be possible though that TLS is used without encryption, i.e. only with authentication and integrity check. Up to TLS version 1.2 there were the NULL ciphers which made this possible. In practice no sane server will implement this. If the client still tries to use such cipher the TLS handshake will fail since there is no common cipher between client and server.
See also Unencrypted SSL protocol?.
I'm developing a client-server application which uses WebSocket. I have implemented token-based authentication with JWT. Once my client has a valid token, a WebSocket connection is opened indefinitely.
Is it a good idea to send the token within each request? Is there any chance of anyone to hijack the connection?
My question actually applies to any TCP-based connection which requires authentication.
Is there any chance of anyone to hijack the connection? ... My question actually applies to any TCP-based connection which requires authentication.
Yes it is possible to hijack existing TCP connections or just be the man in the middle when you start a new one. The protection against this is not to send the authentication within each message because these could be simply replicated by the attacker. Instead use encryption, i.e. wss:// in case of WebSockets or TLS, IPSec or similar in other cases. These protect against both active man in the middle attacks (hijacking) and passive sniffing.
I chose SSL for registration in my game client. The client communicates with the game server which stores a salted/hashed password.
If I use SSL to authenticate users on login, but the game does all of it's communication with UDP packets, how does the server know that the UDP packets it's receiving is from the authenticated user?
Potentially you can provide a token via SSL, and pass that token in your UDP packets. But this is useless without encryption: an attacker can intercept the UDP packet, grab the token and quickly do the attack using stolen token.
Another option would be to exchange symmetric keys via SSL and use those keys to encrypt UDP packets. But to do this properly you would have to also add MAC, an finally you will end up reinventing TLS :).
The best option is to employ DTLS - the flavor of TLS that works over UDP. All your communication will be authenticated and protected this way. Possibility to use DTLS depends on what language/platform you use and what external libraries (if any) you can invoke.
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.