LibJitsi BouncyCastle FIPS port


#21

Have you tried doing test with the this bouncycastle version by itself? Maybe even using the lib as the client on one side and the server on the other? If that worked, you could use your wrapper on one side and Jitsi on the other and go from there.


#22

I think I’m running into a related issue, described here: Meet fails to invite SIP user over Jigase (logs exception)

Newer versions of BouncyCastle seem to implement:

RFC 7627 5.4. If a client or server chooses to continue with a full handshake without
the extended master secret extension, […] the client or server MUST NOT export any
key material based on the new master secret for any subsequent application-level
authentication. In particular, it MUST disable [RFC5705] […].

Jitsi code does seem to export key material, which causes issues.


#23

Guus! Thankyou so much!

I believe you are correct.

Commenting out the exportKeyingMaterial sections at [src/org/jitsi/impl/neomedia/transform/dtls/DtlsPacketTransformer.java:656] seems to have resolved the issues with the DTLS handshake. It seems to succeed nearly every time now, and much more immediately.


#24

Although I’m happy to help, I don’t understand much of what’s going on. I’m assuming that this export is used for something? What is breaking, by removing that code?


#25

It may break things, I’m only paying attention to the DTLS Handshake at the moment.

I’ll let you know what I find.

The exportKeyingMaterial call doesn’t appear to have any dependencies or side effects that effect other things in that function. I think it’s effecting things inside of BouncyCastle only.

Admittedly I am flying blind here too, and am now looking to try to understand exactly what is going on.


#26

We use that keying material to encrypt/decrypt SRTP.


#27

After several attempts, I have managed to reproduce the original issue with the dtls negotiation anyways, and now it reproduces reliably…

Sorry for the premature victory celebration, I’m in bad need of some rays of light at the end of this tunnel.

I think these are either unrelated, or maybe both hitting on something underneath that is using a shared resource less by being commented out.

It almost seems like there is some shared resource that gets exhausted.

I have noticed a tendency for it to work several times in a row after I have stepped away from the computer for a while.

I wonder if the FIPS library is using some entropy buffer or the like for obtaining random data, and that it maybe has to wait for it to be filled again, and this may be what is causing delays.


#28

Yeah, it’s definitely anything hitting SecureRandom, which makes sense that it’s exhausting linux’s /dev/random

Much simpler than I had thought it would be… I’m trying to figure out the way to configure the FIPS library to use some intermediate source of entropy.


#29

So, -Djava.security.egd=file:/dev/./urandom seems to perhaps solve the blocking issue.

It appears BouncyCastle’s FIPS library uses SecureRandom everywhere internally, and the default SecureRandom that the BCFIPS provider provides also uses /dev/random.

Basically if I let /dev/random fill up with a bit of entropy, all of the calls that go into BouncyCastle would work quickly.

If I exhausted /dev/random, it would block randomly in TlsUtils calls, or anything that touched SecureRandom.


#30

@bbaldino Any thoughts on how I can have the extended master secret generated (or make the Jitsi stack compatible with BouncyCastle 60 in another way)?


#31

Afraid I won’t be much help here as I haven’t looked at updating bouncycastle much at all. When I took a look at the DTLS code when starting the rewrite work I considered upgrading it (at that time I noticed the APIs we were using were deprecated) but decided to leave the work for later. It is definitely on my list of things to revisit once the code is stable, but I’m not sure when I’ll get to it.


#32

@Guus_der_Kinderen

If your problem is that the extended_master_secret is tripping things up because it’s being advertised in the DTLS handshake process, the TlsClientImpl that Jitsi Videobridge uses extends DefaultTlsClient, and overrides getClientExtensions.

At least in the BouncyCastle FIPS library I’m using, which is based probably on a later bouncycastle, this list comes back as having the extended master secret.

I patched it to get rid of those extra extensions, so they wouldn’t appear in the ClientHello:

src/org/jitsi/impl/neomedia/transform/dtls/TlsClientImpl.java:169

    Hashtable defaultClientExtensions = super.getClientExtensions();

    Hashtable clientExtensions = new Hashtable();
    for(Object key : defaultClientExtensions.keySet()) {
        if(!key.toString().equals("22") && !key.toString().equals("23")) {
            clientExtensions.put(key, defaultClientExtensions.get(key));
        }
    }

#33

I believe my problems are caused the other way around: the extended master secret is expected, but not available.


#34

Agree wrt bcfips. I see them in an old version of jvb logs:

JVB 2019-01-21 21:28:05.204 WARNING: [141] org.jitsi.impl.neomedia.transform.dtls.DatagramTransportImpl.log() Unknown DTLS handshake message type: 75
JVB 2019-01-21 21:28:05.206 WARNING: [141] org.jitsi.impl.neomedia.transform.dtls.DatagramTransportImpl.log() Unknown DTLS handshake message type: -6
JVB 2019-01-21 21:29:56.545 WARNING: [568] org.jitsi.impl.neomedia.transform.dtls.DatagramTransportImpl.log() Unknown DTLS handshake message type: 10
JVB 2019-01-21 21:29:56.553 WARNING: [589] org.jitsi.impl.neomedia.transform.dtls.DatagramTransportImpl.log() Unknown DTLS handshake message type: -49
JVB 2019-01-21 21:29:56.656 WARNING: [589] org.jitsi.impl.neomedia.transform.dtls.DatagramTransportImpl.log() Unknown DTLS handshake message type: 88
JVB 2019-01-21 21:30:55.443 WARNING: [820] org.jitsi.impl.neomedia.transform.dtls.DatagramTransportImpl.log() Unknown DTLS handshake message type: 26
JVB 2019-01-21 21:30:55.455 WARNING: [590] org.jitsi.impl.neomedia.transform.dtls.DatagramTransportImpl.log() Unknown DTLS handshake message type: 22
JVB 2019-01-21 21:30:55.556 WARNING: [590] org.jitsi.impl.neomedia.transform.dtls.DatagramTransportImpl.log() Unknown DTLS handshake message type: 30```

#35

On a slightly related note, I notice that libjitsi includes jnopenssl, which in turn looks like maybe it’s only used inside HMACSHA1.java

Am I right to understand that this is the only reason we libjitsi has a dependency on the system openssl?


#36

I spent the last couple days upgrading bouncycastle and adding support for DTLS 1.2 (only in the new bridge for now). @Jason_Thomas @Guus_der_Kinderen @mstyura I could use some help in the review as I’m by no means a security expert. Can’t merge anything yet as I’m waiting for BC 1.61 to make it to maven, but I’ve put the code up here.


#37

Nor am I. Also, kotlin confuses me :slight_smile:

I’ll note that what you’re doing there with regards to the export of keying material seems to be in line with the change I made earlier - but I’m not comfortable to give any kind of assessment on the validity of the PR, security-wise.


#38

Sorry for not replying sooner. I’m not a security expert either, but I am aspiring to be one :wink:

All of this talk of a new videobridge and all of this Kotlin makes me think there are a lot of changes coming up for Jitsi that I so far have been unaware of.

Give me some time to jump around and get up to speed on the full context of what you are doing, and then maybe I could give it a reasonable review.

So far like Guus said, it seems like you won’t trigger the particular issue with BC that we ran into.

It shows however the FIPS port of libjitsi I did probably won’t be particularly relevant to your current work :frowning:

On a more selfish tangent, if you look at my FIPS branch, the main points there are using the JCA interfaces for accessing and using streams/ciphers, rather than the internal BouncyCastle alternatives.

Basically there is no FIPS ‘crypto’ package. Accessing all of the ciphers through their JCA interface would make it so your future port would be able to more easily drop in FIPS bouncycastle with minimal modification.


#39

Thanks @Jason_Thomas. Any input would be great. I think I’d prefer to delay using the JCA method you described, just until I can at least feel good about this version. And, actually, if you wouldn’t mind dumping any knowledge you’ve accumulated about this stuff that would better help me understand the pieces here, that would be helpful and may ease the transition. I vaguely remembered seeing some JCA alternatives (I think?) but the differences aren’t clear to me.