Hi, We have a problem with running Apache mod_nss with SCA6000 in FIPS mode.. When we disable the "Sun Metaslot", so that nss can use only the Hardware token completely, we get the following error when we try to connect to our server from openssl:
# openssl s_client -connect localhost:443 -tls1 -state CONNECTED(00000005) SSL_connect:before/connect initialization SSL_connect:SSLv3 write client hello A SSL_connect:SSLv3 read server hello A depth=0 /C=US/ST=California/L=Santa Clara/O=Sun/OU=Org/CN=nobody verify error:num=18:self signed certificate verify return:1 depth=0 /C=US/ST=California/L=Santa Clara/O=Sun/OU=Org/CN=nobody verify return:1 SSL_connect:SSLv3 read server certificate A SSL_connect:SSLv3 read server done A SSL_connect:SSLv3 write client key exchange A SSL_connect:SSLv3 write change cipher spec A SSL_connect:SSLv3 write finished A SSL_connect:SSLv3 flush data *SSL3 alert read:fatal:bad record mac ---------------------------------------------------------------*> The fatal error!! SSL_connect:failed in SSLv3 read finished A 1723:error:140943FC:SSL routines:SSL3_READ_BYTES:sslv3 alert bad record mac:../../../../common/openssl/ssl/s3_pkt.c:1052:SSL alert number 20 1723:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:../../../../common/openssl/ssl/s3_pkt.c:529: According to a thread on Opensolaris forum ( http://jp.opensolaris.org/jive/thread.jspa?threadID=64742&tstart=120) "By default, the SCA 6000 does not export any hash algorithm to user space apps because the hw can not support multi-part operations" Output of cryptoadm confirms this: bash-3.00# cryptoadm list -m provider=mca/0 *mca/0*: * ---------------------------------------------------------------*> our Sun Crypto Accelerator CKM_SHA_1,CKM_DES_CBC,CKM_DES3_CBC,CKM_AES_CBC,CKM_AES_CTR,CKM_DES_CBC_PAD,CKM_DES3_CBC_PAD,CKM_AES_CBC_PAD,CKM_RSA_X_509,CKM_RSA_PKCS,CKM_DSA,CKM_DH_PKCS_KEY_PAIR_GEN,CKM_DH_PKCS_DERIVE,CKM_RSA_PKCS_KEY_PAIR_GEN,CKM_DSA_KEY_PAIR_GEN,CKM_DES_KEY_GEN,CKM_DES2_KEY_GEN,CKM_DES3_KEY_GEN,CKM_AES_KEY_GEN,CKM_DES_CBC_PAD,CKM_DES3_CBC_PAD,CKM_AES_CBC_PAD,CKM_DES_CBC,CKM_DES3_CBC,CKM_AES_CBC,CKM_AES_CTR,CKM_RSA_X_509,CKM_RSA_PKCS,0x80004653 (CKM_SHA_1 is the only hashing algorithm we see) This probably means that since I am forcing the NSS to use only hardware token (by disabling Sun Metaslot), even the HMAC hashing algorithm is being looked for in the SCA6000 card. But since it does not expose any hashing algorithm it fails to decode the hash client sends after change cipher spec msg, right? However if using JCE I list out all the supported algorithms of SCA6000, I see even these hashing algs amongst them: Mac.HmacSHA384 Mac.HmacSHA512 Mac.HmacMD5 Mac.SslMacMD5 Mac.HmacSHA1 Mac.SslMacSHA1 Mac.HmacSHA256 So, I tried configuring Tomcat to use the SCA6000 as its JSSE provider, and as I had guessed this worked without a glitch (by this I mean connecting with openssl) !!! I believe that's because for JSSE the above hashing algs are visible. To confirm this, I disabled these hashing algorithms in the sca6000.cfg file used by the JSSE provider and trying with openssl I get an error similar to Apache web server: # openssl s_client -connect localhost:443 -tls1 -state CONNECTED(00000005) SSL_connect:before/connect initialization SSL_connect:SSLv3 write client hello A SSL_connect:SSLv3 read server hello A depth=0 /C=US/ST=California/L=Santa Clara/O=Sun/OU=Org/CN=nobody verify error:num=18:self signed certificate verify return:1 depth=0 /C=US/ST=California/L=Santa Clara/O=Sun/OU=Org/CN=nobody verify return:1 SSL_connect:SSLv3 read server certificate A SSL_connect:SSLv3 read server key exchange A SSL_connect:SSLv3 read server done A SSL_connect:SSLv3 write client key exchange A SSL_connect:SSLv3 write change cipher spec A SSL_connect:SSLv3 write finished A SSL_connect:SSLv3 flush data *SSL3 alert read:fatal:unexpected_message* ----------------------------------------------------------------------------------------> Again after client's change cipher spec SSL_connect:failed in SSLv3 read finished A 2089:error:140943F2:SSL routines:SSL3_READ_BYTES:sslv3 alert unexpected message:../../../../common/openssl/ssl/s3_pkt.c:1052:SSL alert number 10 2089:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:../../../../common/openssl/ssl/s3_pkt.c:529: So the question is, how is JSSE able to access the hashing algorithms while NSS cannot?? Our SCA card and web servers have to be running in FIPS mode too... Any help is greatly appreciated.. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/crypto-discuss/attachments/20090820/345fb55b/attachment.html>
