I created a TLS server that authenticates the client, reads the client request and answers appropriately.
I want to test how my server reacts to bad tls handshake requests, errors and alerts. Is there a client that can test this on my server?
Thanks in advance
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.
Description of the Issue:
I am trying to connect to TLS 1.0 from the windows laptop to Windows IIS server. We have mutual authentication set-up at IIS.
Please see below the calls made for the handshake:
So it starts with client hello on frame no 4. And then in the next steps Server sends it’s certificate and ciphers are negotiated. And then on frame no 12, the handshake seems finished. And on frame no 13, client starts sending the application data.
But then again on frame no 14, Server sends a hello and we see a second handshake. Please can you answer my below query.
Question>> In mutual authentication, Client requests for Server Certificate. And then Server requests for the Client certificate. And when both of them has authenticated each other’s certificate, client starts sending application data. Isn’t this a normal process for mutual authentication?
Question>> On Frame 13, Client has already started sharing the application data. Then why is IIS asking for a second hand-shake on frame 21?
Question>> It seems the second hand-shake is for getting the client certificate ( Frame 24). But shouldn’t the Server ask for the Client certificate before frame 13.
In case you agree that this IIS behaviour is wrong, please can you suggest as how to fix this.
Thanks in advance.
This scenario happens if the server does not require mutual authentication for all resources but only when accessing specific resources. Thus:
The initial handshake without client certificates is done (frames 4..12).
The client sends the HTTP request (frame 13).
Based on the request the server realizes that the clients likes to access a resource which requires mutual authentication. The server thus requests a new handshake using the Hello Request (frame 14).
The new handshake is done, this time with client certificates (frames 15..25).
The server sends the HTTP response after the authentication of the client was successful (frames 26,29).
Based on the documentation Apache allows to request a client cert authentication for one directory and don't request it for another directory.
http://httpd.apache.org/docs/2.2/ssl/ssl_howto.html#arbitraryclients
How is it possible?
I assumed that first TLS/SSL does a handshake (including client certificate validation) and only after it, HTTP request is sent over secured channel. And this HTTP request contains a URL.
So, it looks like to get a URL (a diretory) you need to do (or skip) client certificate authentication.
So, it's not clear for me, how can Apache check URL first and decide later whether to request a client cert authentication or not.
It uses SSL/TLS renegotiation: the server sends a TLS Hello Request message to ask the client to trigger a new handshake by sending a new Client Hello message (and this time the server will send a Certificate Request after its Server Hello message).
The Hello Request message could in principle happen at any time during the HTTP exchange. For this particular feature, the server sends it just after receiving the request (therefore knowing which resource was requested), but before sending its response.
I am developing a secured Websocket server and realized that SSL at least requires server authentication.. That means, clients need to trust my certificates.
Is there a way to show up an "accept certificate" dialog at time the WSS is being established ?
What is the solution then ? Should I put the web application in an HTTPS connection ?
Of course I want to avoid having to manually send certificate to clients and asking them to trust it.
Thanks.
Websockets are not normal sockets. They are established by upgrading an existing HTTP(s) connection, so if you have HTTP they will be unencrypted and with HTTPS they will be encrypted and all the certificate check is already done before the upgrade to WebSockets started.
When trying to use WCF with NetHttpBinding on IIS 8 Express, the following WebSocketException is thrown on client side when the client attempts to connect:
WebSocket upgrade request failed. Received response status code '200 (OK)', expected: '101 (SwitchingProtocols)'.
Google Search is not helpful.
What could be the cause of this error?
It means the HTTP server does not support WebSockets on that URL. During a WebSocket negotiation, a standard HTTP 1.1 GET request is sent to the server with a special Upgrade: websocket header to let the server know that the client wants the connection to use a WebSocket and not HTTP. If the server supports WebSockets, and the request headers are valid, the server is required to send a 101 reply to let the client know that the server is switching the connection over to a WebSocket for the duration of the connection. Any other reply other than a 3xx redirect means means the server does not recognize or allow the Upgrade request on that URL.