Getting "Renegotiation not supported" warning when Server sends "HelloRequest"

[Sakkanan]

Hi!,
Is there a way to handle "HelloRequest" from server in Client. I am getting "Renegotiation not supported" warning message when server sends HelloRequest. followed by "Connection Reset" error.

Client side implementation : BC 1.63, java 8 ( my environment )
Server side implementation : IIS8 ( external environment, I don;t have any control )

log message
o.b.j.p.ProvTlsClient - Client raised warning(1) no_renegotiation(100) alert: Renegotiation not supported o.b.j.p.ProvTlsClient - Client raised fatal(2) internal_error(80) alert: Failed to read record
stacktrace
java.net.SocketException: Connection reset at java.net.SocketInputStream.read(SocketInputStream.java:210) at java.net.SocketInputStream.read(SocketInputStream.java:141) at org.bouncycastle.tls.RecordStream$Record.fillTo(Unknown Source) at org.bouncycastle.tls.RecordStream$Record.readHeader(Unknown Source) at org.bouncycastle.tls.RecordStream.readRecord(Unknown Source) at org.bouncycastle.tls.TlsProtocol.safeReadRecord(Unknown Source) at org.bouncycastle.tls.TlsProtocol.readApplicationData(Unknown Source) at org.bouncycastle.jsse.provider.ProvSSLSocketWrap$AppDataInput.read(Unknown Source) at okio.Okio$2.read(Okio.java:140) at okio.AsyncTimeout$2.read(AsyncTimeout.java:237

is there a workaround to this issue?

Thank you very much for the time and help

[peterdettman]

Unfortunately our TLS libraries do not support renegotiation (and we do not plan to add it, although there are corresponding TLS 1.3 features that we will).

You have joined 2 log messages above. When the server sends a HelloRequest, we reply with a no_renegotiation warning alert (the standard way to say "no, thanks") - that's the first log entry. This is not inherently a failure, but the server can then decide it doesn't want to proceed and fail the connection - which causes the second log entry.

A typical scenario where this happens is when the server application is written specifically to ask for client authentication at some time after an initial (anonymous) connection was made.

So there isn't really a workaround except that the server application would be rewritten not to depend on the client supporting renegotiation, usually by expecting a new connection instead of renegotiating an existing one.

[Sakkanan]

Thank you @peterdettman for the clarification.

The scenario is REST-Client (BC 1.63, java 8) tries to connect to a server ( IIS8) using mutual auth.
There is no prior connection with the server, so no need for server to renegotiate.

But in this case, server sends 'HelloRequest' right after the first Handshake is done;

OpenSSL/curl client works; Is there any specific reason why renegotiation is not supported at the client side? I am looking for technical reason ( Like to mitigate, man-in-the middle, DoS attack ) to decide the possible solution

Thanks a lot !

[peterdettman]

I'm not sure why the server is trying to renegotiate immediately if your initial client connection already uses client-auth. It could be an inadvertent setting on the server that could simply be disabled, or there could be something else it's trying to achieve.

Initially we didn't implement renegotiation because it was woefully underspecified while promising to be very complicated to get right (whatever that would mean). Later a series of increasingly devastating attacks showed renegotiation to be fraught with security issues.

So for us it went from the too hard basket right into the too insecure basket. It's doubtful whether anyone really implements renegotiation correctly, in part because it's not clear what that would actually mean.

[winfriedgerlach]

@Sakkanan @peterdettman can this issue be closed?

[PackiarajSakkananGW]

Yes, please close it.
thanks