X

Blogs about Deep Learning, Machine Learning, AI, NLP, Security, Oracle Traffic Director,Oracle iPlanet WebServer

  • September 21, 2011

More about PKCS11 Bypass in Oracle iPlanet Web Server 7.0

More about PKCS11 Bypass in Oracle iPlanet Web Server 7.0

Jyri's blog explains the concepts about PKCS11 Bypass in Oracle iPlanet Web server 7.0.

    By default in Oracle iPlanet Web Server 7.0, PKCS11Bypass is enabled. To know if PKCS11 Bypass is actually enabled or disabled in your server instance, run the server instance in <log-level>fine</log-level> and check the error log for lines containing the words "PKCS11 bypass". 

When PKCS11 Bypass is enabled When PKCS11 Bypass is disabled
server.xml

<pkcs11>
   <allow-bypass>true</allow-bypass>
</pkcs11>

<pkcs11>
   <allow-bypass>false</allow-bypass>
</pkcs11>

Error log

fine: PKCS#11 bypass is enabled

fine: PKCS#11 bypass is disabled


    Even though PKCS11 Bypass is enabled in server.xml, it is possible that that check of "SSL_CanBypass" fails in that case PKCS11 Bypass is not enabled. So its essential to check error log contents.

    Lets use DTrace scripts to see what's going on at function call level when PKCS11 Bypass is enabled or disabled. Lets analyse the scenario where AES cipher suite is negotiated in SSL Handshake. We know that  "AES_Encrypt" will be called in that case. So we write a script to print stack when "AES_Encrypt" function is called.


#!/usr/sbin/dtrace -s

#pragma D option quiet


pid$1::AES_Encrypt*:entry
{

    printf("thread %d:  stack is : \n", tid);

    ustack();

}

Note that if in SSL Handshake, others cipher suites were negotiated,  for example if RC4 is negotiated, "RC4_Encrypt" function will be called instead of "AES_Encrypt" and so on... Ideally we need a script with the full list of freebl algorithms but for our simple testing this will serve the purpose.

We run this D script and pass the the highest webservd pid as the first argument. Now send a (HTTPS) request via browser to the Web Server instance, here is the stack we get in both the cases (when PKCS11 Bypass is enabled and disabled).


User stack when PKCS11 Bypass is enabled

User stack when PKCS11 Bypass is disabled*

#./ssl.d 22437

thread 17: stack is :

libsoftokn3.so`AES_Encrypt





libssl3.so`ssl3_CompressMACEncryptRecord+0x5a8

libssl3.so`ssl3_SendRecord+0x38c

libssl3.so`ssl3_FlushHandshake+0x1cc

libssl3.so`ssl3_SendFinished+0x448

libssl3.so`ssl3_HandleFinished+0x5a4

libssl3.so`ssl3_HandleHandshakeMessage+0x8d0

libssl3.so`ssl3_HandleHandshake+0x2d8

libssl3.so`ssl3_HandleRecord+0xb60

libssl3.so`ssl3_GatherCompleteHandshake+0x110

libssl3.so`ssl_GatherRecord1stHandshake+0xd0

libssl3.so`ssl_Do1stHandshake+0x308

libssl3.so`ssl_SecureRecv+0x230

libssl3.so`ssl_Recv+0x124

libnspr4.so`PR_Recv+0x48

libns-httpd40.so`int DaemonSession::GetConnection()+0x470

libns-httpd40.so`void DaemonSession::run()+0xdc

libnsprwrap.so`void Thread::run_()+0x28

#./ssl.d 22469

thread 17: stack is :


libsoftokn3.so`AES_Encrypt


libsoftokn3.so`NSC_EncryptUpdate+0x490

libnss3.so`PK11_CipherOp+0x28c



libssl3.so`ssl3_CompressMACEncryptRecord+0x5a8

libssl3.so`ssl3_SendRecord+0x38c

libssl3.so`ssl3_FlushHandshake+0x1cc

libssl3.so`ssl3_SendFinished+0x448

libssl3.so`ssl3_HandleFinished+0x5a4

libssl3.so`ssl3_HandleHandshakeMessage+0x8d0

libssl3.so`ssl3_HandleHandshake+0x2d8

libssl3.so`ssl3_HandleRecord+0xb60

libssl3.so`ssl3_GatherCompleteHandshake+0x110

libssl3.so`ssl_GatherRecord1stHandshake+0xd0

libssl3.so`ssl_Do1stHandshake+0x308

libssl3.so`ssl_SecureRecv+0x230

libssl3.so`ssl_Recv+0x124

libnspr4.so`PR_Recv+0x48

libns-httpd40.so`int DaemonSession::GetConnection()+0x470

libns-httpd40.so`void DaemonSession::run()+0xdc

libnsprwrap.so`void Thread::run_()+0x28


*Note that we see calls to NSS softoken starting with NSC_.  If we use libpkcs11.so, the names of the symbols to look might be different, i.e. C_Encrypt, C_Decrypt.

From the above results we find that 

  • When PKCS11 Bypass is enabled,  function "ssl3_CompressMACEncryptRecord" (and others) in libssl3.so directly call "AES_Encrypt" in the same library (i.e. libssl3.so).
  • When PKCS11 Bypass is disabled,  it calls "PK11_CipherOP" function in libnss3.so which then calls "NSC_EncryptUpdate" function in libsofttoken3.so which in turn calls "AES_Encrypt" function in libsofttoken3.so. 

So by enabling PKCS11 Bypass we are eliminating two layers of function calls and that's why its faster. 

References

http://blogs.oracle.com/jyrivirkki/entry/pkcs_11_and_ssl_performance

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.