Possible issue with BC 1.59 DTLS handshake

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Possible issue with BC 1.59 DTLS handshake

Mondain
I'm part of a team using BC 1.59 on the server-side for WebRTC and I'm running into issues after integrating with this latest BC version; previously we used BC 1.55 with some patches. I've studied RFC 6347 and I don't seem to see what I'd expect as far as the state process and I'm wondering if I've misconfigured something in my TlsServerImpl to prevent ServerHello being sent when the server is configured as "passive" and the connecting browser is "actpass". We use self-signed ECDSA certificates that are generated at server startup for further background. 
I'm testing with Chrome 66 and Firefox 59 and Firefox seems to work just fine and chrome fails. What I see happening with both browsers is that they send several request hello packets and our server responds with a request hello and a client hello (which seems like it should be server hello?). Firefox will then respond with more request hello and a client hello and soon after the connection is completed. Whereas with Chrome it continues to respond with only request hello and later the server times out the connection.
I've check and double checked everything; I even reduced the supported ciphers to the two supported by both browsers: [49195, 52392].

Any ideas would be great!

Best Regards,
Paul
Reply | Threaded
Open this post in threaded view
|

Re: Possible issue with BC 1.59 DTLS handshake

Tim Panton new


On 24 Apr 2018, at 22:59, Mondain <[hidden email]> wrote:

I'm part of a team using BC 1.59 on the server-side for WebRTC and I'm running into issues after integrating with this latest BC version; previously we used BC 1.55 with some patches. I've studied RFC 6347 and I don't seem to see what I'd expect as far as the state process and I'm wondering if I've misconfigured something in my TlsServerImpl to prevent ServerHello being sent when the server is configured as "passive" and the connecting browser is "actpass". We use self-signed ECDSA certificates that are generated at server startup for further background. 
I'm testing with Chrome 66 and Firefox 59 and Firefox seems to work just fine and chrome fails. What I see happening with both browsers is that they send several request hello packets and our server responds with a request hello and a client hello (which seems like it should be server hello?). Firefox will then respond with more request hello and a client hello and soon after the connection is completed. Whereas with Chrome it continues to respond with only request hello and later the server times out the connection.
I've check and double checked everything; I even reduced the supported ciphers to the two supported by both browsers: [49195, 52392].

Any ideas would be great!

Best Regards,
Paul

I can’t give you specific advice, except to say that I now have this working ok in 1.59 - _but_ there was a breaking change in 1.55->1.59 update
you _have_ to extract the SRTP keys (exportKeyingMaterial() ) during the handshake (notifyHandshakeComplete() )
- we had been doing it later and that threw an exception in 1.59 .

Tim.

 
Reply | Threaded
Open this post in threaded view
|

Re: Possible issue with BC 1.59 DTLS handshake

Mondain
Thanks Tim, I think you helped me out before when I migrated from 1.55 to 1.59; the notifyHandshakeComplete was key in that instance and having to rework the protection profile setup etc. I will look into the exportKeyingMaterial() method and see how and when we're accessing it.

Paul

On Tue, Apr 24, 2018 at 2:08 PM westhawk <[hidden email]> wrote:


On 24 Apr 2018, at 22:59, Mondain <[hidden email]> wrote:

I'm part of a team using BC 1.59 on the server-side for WebRTC and I'm running into issues after integrating with this latest BC version; previously we used BC 1.55 with some patches. I've studied RFC 6347 and I don't seem to see what I'd expect as far as the state process and I'm wondering if I've misconfigured something in my TlsServerImpl to prevent ServerHello being sent when the server is configured as "passive" and the connecting browser is "actpass". We use self-signed ECDSA certificates that are generated at server startup for further background. 
I'm testing with Chrome 66 and Firefox 59 and Firefox seems to work just fine and chrome fails. What I see happening with both browsers is that they send several request hello packets and our server responds with a request hello and a client hello (which seems like it should be server hello?). Firefox will then respond with more request hello and a client hello and soon after the connection is completed. Whereas with Chrome it continues to respond with only request hello and later the server times out the connection.
I've check and double checked everything; I even reduced the supported ciphers to the two supported by both browsers: [49195, 52392].

Any ideas would be great!

Best Regards,
Paul

I can’t give you specific advice, except to say that I now have this working ok in 1.59 - _but_ there was a breaking change in 1.55->1.59 update
you _have_ to extract the SRTP keys (exportKeyingMaterial() ) during the handshake (notifyHandshakeComplete() )
- we had been doing it later and that threw an exception in 1.59 .

Tim.

 
Reply | Threaded
Open this post in threaded view
|

Re: Possible issue with BC 1.59 DTLS handshake

Mondain
Still though, it seems very odd that its all request hello and client hello, but never any server hello. With BC's abstract parent server class and the dtlsrecordlayer calling into send and receive, I'm not certain there's going to be a intuitive means for implementing ServerHello and / or HelloVerifyRequest. 

On Tue, Apr 24, 2018 at 2:14 PM Mondain <[hidden email]> wrote:
Thanks Tim, I think you helped me out before when I migrated from 1.55 to 1.59; the notifyHandshakeComplete was key in that instance and having to rework the protection profile setup etc. I will look into the exportKeyingMaterial() method and see how and when we're accessing it.

Paul

On Tue, Apr 24, 2018 at 2:08 PM westhawk <[hidden email]> wrote:


On 24 Apr 2018, at 22:59, Mondain <[hidden email]> wrote:

I'm part of a team using BC 1.59 on the server-side for WebRTC and I'm running into issues after integrating with this latest BC version; previously we used BC 1.55 with some patches. I've studied RFC 6347 and I don't seem to see what I'd expect as far as the state process and I'm wondering if I've misconfigured something in my TlsServerImpl to prevent ServerHello being sent when the server is configured as "passive" and the connecting browser is "actpass". We use self-signed ECDSA certificates that are generated at server startup for further background. 
I'm testing with Chrome 66 and Firefox 59 and Firefox seems to work just fine and chrome fails. What I see happening with both browsers is that they send several request hello packets and our server responds with a request hello and a client hello (which seems like it should be server hello?). Firefox will then respond with more request hello and a client hello and soon after the connection is completed. Whereas with Chrome it continues to respond with only request hello and later the server times out the connection.
I've check and double checked everything; I even reduced the supported ciphers to the two supported by both browsers: [49195, 52392].

Any ideas would be great!

Best Regards,
Paul

I can’t give you specific advice, except to say that I now have this working ok in 1.59 - _but_ there was a breaking change in 1.55->1.59 update
you _have_ to extract the SRTP keys (exportKeyingMaterial() ) during the handshake (notifyHandshakeComplete() )
- we had been doing it later and that threw an exception in 1.59 .

Tim.

 
Reply | Threaded
Open this post in threaded view
|

Re: Possible issue with BC 1.59 DTLS handshake

Mondain
It appears that I did implement the export within an internal call to notifyHandshakeComplete; heres a pastebin of that method just in case something is incorrect for an ECDSA setup instead of RSA. https://pastebin.com/cvkLVBX7


On Tue, Apr 24, 2018 at 2:17 PM Mondain <[hidden email]> wrote:
Still though, it seems very odd that its all request hello and client hello, but never any server hello. With BC's abstract parent server class and the dtlsrecordlayer calling into send and receive, I'm not certain there's going to be a intuitive means for implementing ServerHello and / or HelloVerifyRequest. 

On Tue, Apr 24, 2018 at 2:14 PM Mondain <[hidden email]> wrote:
Thanks Tim, I think you helped me out before when I migrated from 1.55 to 1.59; the notifyHandshakeComplete was key in that instance and having to rework the protection profile setup etc. I will look into the exportKeyingMaterial() method and see how and when we're accessing it.

Paul

On Tue, Apr 24, 2018 at 2:08 PM westhawk <[hidden email]> wrote:


On 24 Apr 2018, at 22:59, Mondain <[hidden email]> wrote:

I'm part of a team using BC 1.59 on the server-side for WebRTC and I'm running into issues after integrating with this latest BC version; previously we used BC 1.55 with some patches. I've studied RFC 6347 and I don't seem to see what I'd expect as far as the state process and I'm wondering if I've misconfigured something in my TlsServerImpl to prevent ServerHello being sent when the server is configured as "passive" and the connecting browser is "actpass". We use self-signed ECDSA certificates that are generated at server startup for further background. 
I'm testing with Chrome 66 and Firefox 59 and Firefox seems to work just fine and chrome fails. What I see happening with both browsers is that they send several request hello packets and our server responds with a request hello and a client hello (which seems like it should be server hello?). Firefox will then respond with more request hello and a client hello and soon after the connection is completed. Whereas with Chrome it continues to respond with only request hello and later the server times out the connection.
I've check and double checked everything; I even reduced the supported ciphers to the two supported by both browsers: [49195, 52392].

Any ideas would be great!

Best Regards,
Paul

I can’t give you specific advice, except to say that I now have this working ok in 1.59 - _but_ there was a breaking change in 1.55->1.59 update
you _have_ to extract the SRTP keys (exportKeyingMaterial() ) during the handshake (notifyHandshakeComplete() )
- we had been doing it later and that threw an exception in 1.59 .

Tim.

 
Reply | Threaded
Open this post in threaded view
|

Re: Possible issue with BC 1.59 DTLS handshake

Tim Panton new
In reply to this post by Mondain
Yeah, odd.

In our implementation we create a DTLSServer instance when ICE completes and we know that we are a server (i.e. passive).

public abstract class DTLSServer extends
        DefaultTlsServer 


If we are active we create a DTLSClient 
public abstract class DTLSClient extends
        org.bouncycastle.crypto.tls.DefaultTlsClient

Dunno if that helps. (I suspect those two parent classes will be deprecated in the future).

T.


On 24 Apr 2018, at 23:17, Mondain <[hidden email]> wrote:

Still though, it seems very odd that its all request hello and client hello, but never any server hello. With BC's abstract parent server class and the dtlsrecordlayer calling into send and receive, I'm not certain there's going to be a intuitive means for implementing ServerHello and / or HelloVerifyRequest. 

On Tue, Apr 24, 2018 at 2:14 PM Mondain <[hidden email]> wrote:
Thanks Tim, I think you helped me out before when I migrated from 1.55 to 1.59; the notifyHandshakeComplete was key in that instance and having to rework the protection profile setup etc. I will look into the exportKeyingMaterial() method and see how and when we're accessing it.

Paul

On Tue, Apr 24, 2018 at 2:08 PM westhawk <[hidden email]> wrote:


On 24 Apr 2018, at 22:59, Mondain <[hidden email]> wrote:

I'm part of a team using BC 1.59 on the server-side for WebRTC and I'm running into issues after integrating with this latest BC version; previously we used BC 1.55 with some patches. I've studied RFC 6347 and I don't seem to see what I'd expect as far as the state process and I'm wondering if I've misconfigured something in my TlsServerImpl to prevent ServerHello being sent when the server is configured as "passive" and the connecting browser is "actpass". We use self-signed ECDSA certificates that are generated at server startup for further background. 
I'm testing with Chrome 66 and Firefox 59 and Firefox seems to work just fine and chrome fails. What I see happening with both browsers is that they send several request hello packets and our server responds with a request hello and a client hello (which seems like it should be server hello?). Firefox will then respond with more request hello and a client hello and soon after the connection is completed. Whereas with Chrome it continues to respond with only request hello and later the server times out the connection.
I've check and double checked everything; I even reduced the supported ciphers to the two supported by both browsers: [49195, 52392].

Any ideas would be great!

Best Regards,
Paul

I can’t give you specific advice, except to say that I now have this working ok in 1.59 - _but_ there was a breaking change in 1.55->1.59 update
you _have_ to extract the SRTP keys (exportKeyingMaterial() ) during the handshake (notifyHandshakeComplete() )
- we had been doing it later and that threw an exception in 1.59 .

Tim.

 

Reply | Threaded
Open this post in threaded view
|

Re: Possible issue with BC 1.59 DTLS handshake

Mondain
Yes, our code is similar only an active setup spawns a dtls client. Did you guys override the DTLSRecordLayer classes? We didn't.

On Tue, Apr 24, 2018 at 2:29 PM westhawk <[hidden email]> wrote:
Yeah, odd.

In our implementation we create a DTLSServer instance when ICE completes and we know that we are a server (i.e. passive).

public abstract class DTLSServer extends
        DefaultTlsServer 


If we are active we create a DTLSClient 
public abstract class DTLSClient extends
        org.bouncycastle.crypto.tls.DefaultTlsClient

Dunno if that helps. (I suspect those two parent classes will be deprecated in the future).

T.


On 24 Apr 2018, at 23:17, Mondain <[hidden email]> wrote:

Still though, it seems very odd that its all request hello and client hello, but never any server hello. With BC's abstract parent server class and the dtlsrecordlayer calling into send and receive, I'm not certain there's going to be a intuitive means for implementing ServerHello and / or HelloVerifyRequest. 

On Tue, Apr 24, 2018 at 2:14 PM Mondain <[hidden email]> wrote:
Thanks Tim, I think you helped me out before when I migrated from 1.55 to 1.59; the notifyHandshakeComplete was key in that instance and having to rework the protection profile setup etc. I will look into the exportKeyingMaterial() method and see how and when we're accessing it.

Paul

On Tue, Apr 24, 2018 at 2:08 PM westhawk <[hidden email]> wrote:


On 24 Apr 2018, at 22:59, Mondain <[hidden email]> wrote:

I'm part of a team using BC 1.59 on the server-side for WebRTC and I'm running into issues after integrating with this latest BC version; previously we used BC 1.55 with some patches. I've studied RFC 6347 and I don't seem to see what I'd expect as far as the state process and I'm wondering if I've misconfigured something in my TlsServerImpl to prevent ServerHello being sent when the server is configured as "passive" and the connecting browser is "actpass". We use self-signed ECDSA certificates that are generated at server startup for further background. 
I'm testing with Chrome 66 and Firefox 59 and Firefox seems to work just fine and chrome fails. What I see happening with both browsers is that they send several request hello packets and our server responds with a request hello and a client hello (which seems like it should be server hello?). Firefox will then respond with more request hello and a client hello and soon after the connection is completed. Whereas with Chrome it continues to respond with only request hello and later the server times out the connection.
I've check and double checked everything; I even reduced the supported ciphers to the two supported by both browsers: [49195, 52392].

Any ideas would be great!

Best Regards,
Paul

I can’t give you specific advice, except to say that I now have this working ok in 1.59 - _but_ there was a breaking change in 1.55->1.59 update
you _have_ to extract the SRTP keys (exportKeyingMaterial() ) during the handshake (notifyHandshakeComplete() )
- we had been doing it later and that threw an exception in 1.59 .

Tim.

 

Reply | Threaded
Open this post in threaded view
|

Re: Possible issue with BC 1.59 DTLS handshake

Tim Panton new
Nope, but we do override a few methods here and there.

T.


On 24 Apr 2018, at 23:33, Mondain <[hidden email]> wrote:

Yes, our code is similar only an active setup spawns a dtls client. Did you guys override the DTLSRecordLayer classes? We didn't.

On Tue, Apr 24, 2018 at 2:29 PM westhawk <[hidden email]> wrote:
Yeah, odd.

In our implementation we create a DTLSServer instance when ICE completes and we know that we are a server (i.e. passive).

public abstract class DTLSServer extends
        DefaultTlsServer 


If we are active we create a DTLSClient 
public abstract class DTLSClient extends
        org.bouncycastle.crypto.tls.DefaultTlsClient

Dunno if that helps. (I suspect those two parent classes will be deprecated in the future).

T.


On 24 Apr 2018, at 23:17, Mondain <[hidden email]> wrote:

Still though, it seems very odd that its all request hello and client hello, but never any server hello. With BC's abstract parent server class and the dtlsrecordlayer calling into send and receive, I'm not certain there's going to be a intuitive means for implementing ServerHello and / or HelloVerifyRequest. 

On Tue, Apr 24, 2018 at 2:14 PM Mondain <[hidden email]> wrote:
Thanks Tim, I think you helped me out before when I migrated from 1.55 to 1.59; the notifyHandshakeComplete was key in that instance and having to rework the protection profile setup etc. I will look into the exportKeyingMaterial() method and see how and when we're accessing it.

Paul

On Tue, Apr 24, 2018 at 2:08 PM westhawk <[hidden email]> wrote:


On 24 Apr 2018, at 22:59, Mondain <[hidden email]> wrote:

I'm part of a team using BC 1.59 on the server-side for WebRTC and I'm running into issues after integrating with this latest BC version; previously we used BC 1.55 with some patches. I've studied RFC 6347 and I don't seem to see what I'd expect as far as the state process and I'm wondering if I've misconfigured something in my TlsServerImpl to prevent ServerHello being sent when the server is configured as "passive" and the connecting browser is "actpass". We use self-signed ECDSA certificates that are generated at server startup for further background. 
I'm testing with Chrome 66 and Firefox 59 and Firefox seems to work just fine and chrome fails. What I see happening with both browsers is that they send several request hello packets and our server responds with a request hello and a client hello (which seems like it should be server hello?). Firefox will then respond with more request hello and a client hello and soon after the connection is completed. Whereas with Chrome it continues to respond with only request hello and later the server times out the connection.
I've check and double checked everything; I even reduced the supported ciphers to the two supported by both browsers: [49195, 52392].

Any ideas would be great!

Best Regards,
Paul

I can’t give you specific advice, except to say that I now have this working ok in 1.59 - _but_ there was a breaking change in 1.55->1.59 update
you _have_ to extract the SRTP keys (exportKeyingMaterial() ) during the handshake (notifyHandshakeComplete() )
- we had been doing it later and that threw an exception in 1.59 .

Tim.