At this time, our SSL tests include testing for the bypass feature. In these tests, the server and client enables an extra option on the SSL socket. However, unlike other SSL socket options which turn on protocols, cipher suites, or client authentication, there is currently no way to ensure that the bypass option actually is turned on and accomplishing anything. We found yesterday for example that some tests were trying to turn on bypass for SSL2, but this had no effect (or actually an unintended effect - see bug 350771 ) . There was no way in the QA to detect this invalid test because libssl fell back to using PKCS#11 . This is a difficult problem to solve. I can think of 2 ways to check that bypass is working. 1) Benchmark performance with and without it. But this is generally not doable in our automated scripts which sometimes run in parallel or on shared machines. So, we would need some dedicated undisrupted machines to run these performance tests without parallelism. These could be old, slow single-CPU machines. 2) The hard way. a) libssl to keep track of whether it actually bypassed, as opposed to just the option being turned on . Hopefully it already does that somewhere . b) libssl to have an API to get at that information (maybe as part of SSL_GetChannelInfo / SSL_GetCipherSuiteInfo) c) have the QA tools such as tstclnt / strsclnt / selfserv be able to retrieve the info by calling this API d) have the QA scripts enforce the This is obviously much more work than the first method, but it is not fool proof - the libssl API in b) could have a bug, and the test would never know any better.

Will be in valid when bug 1303224 lands.

*invalid of course