I have a problem with the configuration of ocserv on CentOS 8. When I try to connect, a DTLS handshake problem occurs on the client side:
16:50:51 LIB: DTLS handshake timed out
16:50:51 LIB: DTLS handshake failed: Resource temporarily unavailable, try again.
I tried to re-configure according to some guides, but no results. I'd appreciate any help.
Related
I have TLS program and I did some experiments on it.
I start confidential TLS server session and try to connect to it with pure Telnet client.
As expected, the handshake failed and the server is available to the next client but on the Telnet client side I didn't receive any indication that the handshake failed and that the server is accepting other clients.
I can see in Wireshark that even after the handshake failed the Telnet client can send strings; I see [PSH, ACK] from the client answered by [ACK] from the server.
Adding Wireshark snapshot, Telnet failed the handshake, Telnet keep sending messages, followed by success in the TLS handshake and more Telnet messages:
Why is the server ACKing the Telnet client if the handshake failed and he is accepting other clients?
As expected, the handshake failed ...
I cannot see a failed TLS handshake in the packet capture and I'm not sure how you come to this conclusion.
All I can see that the client on source port 60198 (presumable your telnet) is sending 3 bytes several times and the server just ACK'ing these without sending anything back and without closing the connection. Likely the server is still expecting data in the hope that at some time it will be a complete TLS record. Only then it will be processed by the TLS stack and then it might realize that something is wrong with the client.
... the server is available to the next client
It is pretty normal for a server to handle multiple clients in parallel. In contrary, it would be unusual if the server could not do this.
If a web server fails to complete TLS handshake and returns error to TLS client (i.e. browser), does a typical TLS client such as chrome browser retry the handshake a few times before giving up? And if it does retry how many retries? Also is there a TLS handshake timeout in chrome, past that would it retry or just give up ?
In the past browsers tried the TLS handshake itself with an older TLS version in the hope that it will succeed then. Today browsers usually don't do this anymore, i.e. if the initial connection fails they don't retry.
Also is there a TLS handshake timeout in chrome
There is one, i.e. the browser will not wait forever for the server to reply but give up after a while.
I am in a big issue regarding TLSv1.2 and unable to resolve this.
Scenario:
Hostapd should act as an integrated EAP server.I have an openwrt device on which hostapdv2.6-devel is running.
2.Wpa_Supplicant is acting as a client and should talk to hostapd for successful authentication.wpa_supplicantv2.6-devel is running on a different openwrt device.
3.Two way SSL handshake(EAP-TLS) should happen successfully and hostapd should authenticate the client device without any issue.
4.Requirement is that this communication should take place on TLSv1.2 i.e. server (hostapd)is bound to send TLSv1.2.
Configuration:
EAP server(hostapd configuration):
1.Since by default server is sending TLSv1.0 to the client so I made it to send TLSv1.2 forcefully by recompiling the package for TLSv12 and install again on the router.
2.Created a configuration file, which has all the server certificate, ca certificate chain eap_server=1 etc.
3.Started the hostapd process on the device successfully.
client configuration(wpa_supplicant):
1.Created a configuration file, which has all client certificate, CA chain, identity, SSID etc.
2.Started the wpa_supplicant on the device successfully.
SSL transactions:
1.client send client hello message and TLSv1.2 in it.
2.Server responds with server hello message and TLSv1.2
3.Server sends its certificate, serverkeyexchange, certificate request message.
4.Afterward a fatal alert occurs "decode_error" and no more transaction are seen and authentication gets failed.
Please see the wireshark capture below.
ClientHello
ServerHello
Alert Message
Kindly help me to resolve this issue as its making my life difficult.
Please let me know if any other information is required.
Thanks.
Is there any mock target than I can hit that just hangs up during an SSL handshake and the connection would then timeout
I'm running an nginx server with SSL enabled.
My protocol / cipher settings are fairly secure, and I've checked them at ssllabs.com, but --
-- since this is a web service which is called by http clients that I have no control over, I have concerns about compatibility.
To the point:
Is there a way to log SSL handshake failures as they happen (if they happen) in my nginx logs?
For example, I've got SSLv3 disabled, and if I try to "curl -3" (forcing SSlv3) to my server, then I get this:
NSS error -12286 (SSL_ERROR_NO_CYPHER_OVERLAP)
Cannot communicate securely with peer: no common encryption algorithm(s).
Closing connection 0 curl: (35) Cannot communicate securely with peer: no common encryption algorithm(s).
I would like to log this type of error in server logs too, with the default nginx settings, there is nothing.
Enabling "debug" log level for the error log does what I want, will log SSL handshake errors -- but unfortunately it also logs too much other stuff, making the log too bloated, drowning out other potentially useful info.
You can use the info log level.