0

I am writing a messaging client that should connect to a server using websocket secure(WSS). When the client initiates nopoll connection, openssl returns SSL_ERROR_SYSCALL.

The server also supports https-sse protocol. So, to confirm that the x.509 certificates used are correct, I tried connecting to the server using https-sse. This works as expected.

Since the server uses the same certificates to authenticate clients connecting over wss or https, I don't understand why wss connection would fail with SSL_ERROR_SYSCALL when https connection can work with the same server.

Server ip address and port number are the same of WSS and HTTPS. They differ only in the schema. wss://: and https://: Client supporting both wss and https is written in C language as it is intended to be an existing product running code written in C.

Improve this question
8
  • I think this is missing enough details to answer. Do both protocols use the same target name and port, i.e. differ only between https and wss? Do you access both URL's with the same client (browser, app...)? Can you provide the URL's for both https and wss in case they are public? And if not - can you provide packet captures (as full pcap, maybe at cloudshark.org) for successful (https) and unsuccessful (wss) connection?
    – Steffen Ullrich
    May 23, 2017 at 17:12
  • SSL_ERROR_SYSCALL is an internal error and is not related to security. Perhaps ask at Serverfault or Stackoverflow, whichever is more relevant to your question.
    – Oskar Skog
    May 23, 2017 at 17:42
  • 1
    @OskarSkog: this error often comes if the server or a firewall closes the connection with RESET. This can for example happen because of specifics of the TLS handshake and thus might be related to security. But it is hard to tell with only the few information provided. Serverfault and Stackoverflow will not be able to help here too simply because information are missing to reproduce or further look at the issue.
    – Steffen Ullrich
    May 23, 2017 at 17:47
  • Ah, right. That would cause a syscall to fail. Didn't expect an external failure.
    – Oskar Skog
    May 23, 2017 at 20:02
  • Given that the OP did not add any additionally requested information to the page so far I propose it as too broad since it cannot be answered based on the provided information alone.
    – Steffen Ullrich
    May 23, 2017 at 20:13

1 Answer 1

Reset to default
0

The websocket client process used nopoll library that needed access to /dev/urandom as it called random() to generate seed. But the process itself was running in a linux container that did not have access to /dev/urandom. So the client was unable to generate keys during TLS handshake.

Mounting /dev/urandom to the client container resolved the issue.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .