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.
Related
The typical scenario:
The client sends his credentials to the server in a POST request using HTTPS.
The server verifies that the credentials are the right ones and authenticates the user. Thus it returns a JWT (JSON Web Token) to the client.
The client opens a non secured WebSocket connection (ws://). So the client and the server now have a channel to exchange data easily (the exact reasons don't matter here).
The user sends any kind of requests to the server through the WebSocket along with the JWT, so the server can verify that these requests are legit.
The server uses the WebSocket channel to return the data asked by the user after it successfully verified the JWT for each request.
Since we used HTTPS, we assume the JWT was not stolen when it was issued (HTTPS could be defeated but let's assume it's sane for our purpose).
The fact that we use a non secured WebSocket means that someone could sniff the traffic of the WebSocket channel and steal the JWT in a heartbeat. So we use a WebSocket Secure (wss://) instead and apply the same previous scenario.
Now that we are using a WebSocket Secure, do we need to keep sending the JWT in each request we make to the server when we use the WSS channel to do so? Or is the WebSocket Secure channel secured enough so both the server and the client are 100% sure (as long as TLS is not defeated) that this channel is legit?
In other words: once a WSS channel has been safely established, can we trust it? (until the connection is closed obviously)
I don't really understand how a WSS connection is established and how it works once it has been established. My understanding is: the critical part is the handshake, and once the handshake is done you can safely rely on the WSS channel (because it prevents MITM attacks using TLS, which WS doesn't do).
I read a lot of stuff these last days about all this but some concepts are still unclear. Any help will be greatly appreciated!
Websockets use a persistent TCP/IP connection.
Using wss is similar to using the HTTPS, which means that once the SSL/TLS handshake is complete, all Websocket data is "wrapped" (usually encoded) in TLS packages.
Assuming the TLS/SSL connection is secure, the Websocket connection will remain secure and could be (and probably should be) authenticated only once.
Hence, there's no reason to keep sending the JWT over and over again. It's a better solution to use the connection's persistent state in order to "assign" a user to the connection.
Side-Note: Although insecure, it would be better to send the JWT once even when using Websocket connection "in the clear" (ws://), since there are less opportunities to sniff out the JWT.
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.
By WebRTC standard all connections should be encrypted via DTLS. This is great. However, unless application verifies authenticity of the peer, the connection is vulnerable to man in the middle (MITM) attack.
The question is how to do this with libWebRTC (http://www.webrtc.org/native-code) specifically in Objective C interface. Ideally, I would like to be able to specify my own certificate for WebRTC connection. In this case I will be able to verify it through my application-specific secure channel. If this is not possible, then what is the suggested approach? I will be grateful for any hints.
The WebRTC specification does not include the signaling layer, i.e., how the fingerprints, ICE candidates, etc are exchanged between peers. This means that in almost all WebRTC applications, there's a signaling socket to rapidly signal the connection with a service which exchanges the information between two peers.
Instead of supplying your own certificates or fingerprints, what you want to do is authenticate the signaling over which those are sent.
Your signaling server effectively is the man-in-the-middle, especially in cases of using an MCU or SFU. It should verify the identity of clients exchanging signaling information, and ensure the signaling information is exchanged between mutually agreeing peers (i.e., calling one another by address, or joining a common "room").
So the answer is: use secure websockets, and authenticate clients sending/receiving WebRTC offer/answer information. If you do that, there's no risk of man-in-the-middle attacks, beyond the risk of any other HTTPS+WSS application.
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.
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.