does anyone try nss on FreeBSD platform?
___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
How to compile nss3.10 on FreeBSD?
i have compiled nss3.10 successful on Windows platform(cygwin), but i ftp the same version nss to a FreeBSD platform, it can't compile? please help me, thanks. bash-2.05b# make nss_build_all "../coreconf/config.mk", line 44: Need an operator "../coreconf/arch.mk", line 56: Missing dependency operator "../coreconf/arch.mk", line 58: Need an operator "../coreconf/arch.mk", line 60: Need an operator "../coreconf/arch.mk", line 69: Missing dependency operator "../coreconf/arch.mk", line 71: Need an operator "../coreconf/arch.mk", line 73: Need an operator Error expanding embedded variable. how to config these files? do i miss something? ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: How to compile nss3.10 on FreeBSD?
> Alex wrote: >> i have compiled nss3.10 successful on Windows platform(cygwin), but i ftp >> the same version nss to a FreeBSD platform, it can't compile? please help >> me, thanks. >> >> bash-2.05b# make nss_build_all >> "../coreconf/config.mk", line 44: Need an operator >> "../coreconf/arch.mk", line 56: Missing dependency operator >> "../coreconf/arch.mk", line 58: Need an operator >> "../coreconf/arch.mk", line 60: Need an operator >> "../coreconf/arch.mk", line 69: Missing dependency operator >> "../coreconf/arch.mk", line 71: Need an operator >> "../coreconf/arch.mk", line 73: Need an operator >> Error expanding embedded variable. > > Here's a thought: Try the build with gmake instead of make. > On some platforms make is gmake. On others, gmake is separate. > NSS makefiles are gmake makefiles. Try using gmake explicitly. > > -- > Nelson B thanks lot. nss3.10 compiled successfully. thanks for your help. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: How to compile nss3.10 on FreeBSD?
> Alex: > > You should also do "gmake -v" to make sure you are > using GNU make 3.79 or later. The latest versions of > NSS require the 'call' function that was added in > GNU make 3.79 (or a very late 3.7x release). > > Why don't you use the latest NSS 3.11.2 release? > > Wan-Teh > > Thanks for your suggestions, I'm using GNU Make 3.80. I made some modifications on NSS 3.10, so I just try compiled it on FreeBSD. I didn't found NSS 3.11.2 release in mozilla website. http://www.mozilla.org/projects/security/pki/nss/ Maybe it didn't update the latest version. Alex ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
about libsectool.a Why I can't use SECU_ReadDERFromFile
I compiled nss on FreeBSD platform, and wrote a program . My program use function SECU_ReadDERFromFile, like this #include "secutil.h" .. rv = SECU_ReadDERFromFile(&certDER, inFile, PR_TRUE); .. This function is in libsectool.a #nm libsectool.a |grep SECU_Read 1290 T SECU_ReadDERFromFile when I compile my program, it can generate .o file. but can't make executable file. error message like this: g++ -o certools ./certool/GetDNToDB.o ./certool/pk12util.o -L. -L./lib -Wl,-rpath-link,./lib -lsectool -lssl3 -lsmime3 -lnss3 -lplc4 -lplds4 -lnspr4 -lpthread -lc -fpic ./lib/libsoftokn3.so: warning: warning: mktemp() possibly used unsafely; consider using mkstemp() ./certool/GetDNToDB.o(.text+0xc9e): In function `GetCertFullDN(char*)': : undefined reference to `SECU_ReadDERFromFile(SECItemStr*, PRFileDesc*, int)' gmake: *** [certool] Error 1 I try other functions in libsectool.a which is defined in secutil.h. it also can't been use. I feel so despondent. Why?? I have already include header file(secutil.h). Anyone can give me some suggestions? Please help me. Many thanks ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: about libsectool.a Why I can't use SECU_ReadDERFromFile
> Alex wrote:
>> I compiled nss on FreeBSD platform, and wrote a program .
>> My program use function SECU_ReadDERFromFile, like this
>>
>> #include "secutil.h"
>> ..
>> rv = SECU_ReadDERFromFile(&certDER, inFile, PR_TRUE);
>> ..
>>
>>
>> This function is in libsectool.a
>>
>> #nm libsectool.a |grep SECU_Read
>> 1290 T SECU_ReadDERFromFile
>>
>> when I compile my program, it can generate .o file. but can't make
>> executable file. error message like this:
>>
>> g++ -o certools ./certool/GetDNToDB.o
>> ./certool/pk12util.o -L. -L./lib -Wl,-rpath-link,./lib -lsectool -lssl3
>> -lsmime3
>> -lnss3 -lplc4 -lplds4 -lnspr4 -lpthread -lc -fpic
>> ./lib/libsoftokn3.so: warning: warning: mktemp() possibly used unsafely;
>> consider using mkstemp()
>> ./certool/GetDNToDB.o(.text+0xc9e): In function `GetCertFullDN(char*)':
>> : undefined reference to `SECU_ReadDERFromFile(SECItemStr*, PRFileDesc*,
>> int)'
>> gmake: *** [certool] Error 1
>>
>> I try other functions in libsectool.a which is defined in secutil.h. it
>> also can't been use. I feel so despondent.
>>
>> Why?? I have already include header file(secutil.h). Anyone can give me
>> some suggestions? Please help me.
>
> Your link command line looks correct. We link our
> command-line utilities with ./lib/libsectool.a instead
> of -L./lib -lsectool, but -L./lib -lsectool should work.
>
> Since you use g++ to link, I suspect that you also GetDNToDB.o
> is compiled from a C++ file. Try include secutil.h in an extern "C"
> block like this:
>
> extern "C" {
> #include "secutil.h"
> }
>
> Note that libsectool.a is for NSS internal use. So
> you are using it at your own risk.
>
> Wan-Teh
Thanks for your help. The problem has been solved by adding extern "C"
block. I'm very grateful. :-)
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
NSS_SetDomesticPolicy() return 12266
Hello,
I wrote a program like this:
PRInt32 mod_ssl_startup(char *dbdir, PRInt32 clearCert)
{
char *dbpath=NULL;
char *certfile=NULL;
PRErrorCode ercode;
SECStatus rv;
PK11SlotInfo *slot=NULL;
..
rv = NSS_InitReadWrite(dbpath);
rv = NSS_SetDomesticPolicy();
if(rv!=SECSuccess)
{
ercode = PR_GetError();
printf("set policy failure..%d\n", ercode);
goto cleanup;
}
..
Why NSS_SetDomesticPolicy always return 12266?
"An unknown SSL cipher suite has been requested."
The application has attempted to configure SSL to use an unknown cipher
suite.
But I didn't do anything. Please tell me why?
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Thanks for suggestions
My NSS version is 3.10. Because of I did some modifications on nss. I try to
add a new cipher to nss, but obviously i made some mistakes.
I don't know what's wrong. How to avoid that error? I list my modifications
here. Do I miss anything?
---
sslsock.c modifications:
..
static cipherPolicy ssl_ciphers[] = {/* Export France */
..
#ifdef NSS_ENABLE_ECC
..
#endif /* NSS_ENABLE_ECC */
/*add for ssf33 support*/
{ SSL_RSA_WITH_SSF33_ECB_SHA, SSL_ALLOWED, SSL_NOT_ALLOWED},
//If I delete this code NSS_SetDomesticPolicy() will return SECSuccess.
/*end add*/
{ 0, SSL_NOT_ALLOWED, SSL_NOT_ALLOWED }
};
--
sslproto.h modifications:
..
#endif /* NSS_ENABLE_ECC */
/*add for ssf33 support*/
#define SSL_RSA_WITH_SSF33_ECB_SHA 0x8009
/*end add*/
/* Netscape "experimental" cipher suites. */
#define SSL_RSA_OLDFIPS_WITH_3DES_EDE_CBC_SHA 0xffe0
#define SSL_RSA_OLDFIPS_WITH_DES_CBC_SHA 0xffe1
/* New non-experimental openly spec'ed versions of those cipher suites. */
#define SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA 0xfeff
#define SSL_RSA_FIPS_WITH_DES_CBC_SHA 0xfefe
#endif /* __sslproto_h_ */
-
sslenum.c modifications:
const PRUint16 SSL_ImplementedCiphers[] = {
..
#ifdef NSS_ENABLE_ECC
..
#endif /* NSS_ENABLE_ECC */
..
#ifdef NSS_ENABLE_ECC
..
#endif /* NSS_ENABLE_ECC */
..
#ifdef NSS_ENABLE_ECC
..
#endif /* NSS_ENABLE_ECC */
..
#ifdef NSS_ENABLE_ECC
..
#endif /* NSS_ENABLE_ECC */
..
#ifdef NSS_ENABLE_ECC
..
#endif /* NSS_ENABLE_ECC */
..
/*add for ssf33 support*/
SSL_RSA_WITH_SSF33_ECB_SHA,
/*end add*/
0
};
---
sslinfo.c modifications:
..
#define C_SSF33_ECB "SSF33_ECB",calg_ssf33_ecb
..
static const SSLCipherSuiteInfo suiteInfo[] = {
/* <-- Cipher suite >
*/
..
/*add for ssf33 support*/
{0,CS(SSL_RSA_WITH_SSF33_ECB_SHA), S_RSA, K_RSA, C_SSF33_ECB,
B_128, M_SHA, 1, 0, 0, }
/*end add*/
};
---
sslimpl.h
..
#define calg_ssf33_ecb ssl_calg_ssf33_ecb
..
/*modi for ssf33 support*/
#ifdef NSS_ENABLE_ECC
#define ssl_V3_SUITES_IMPLEMENTED 41/*40*/
#else
#define ssl_V3_SUITES_IMPLEMENTED 27/*26*/
#endif /* NSS_ENABLE_ECC */
/*end modify*/
..
/* The SSL bulk cipher definition */
typedef enum {
..
..
/*add for ssf33 support*/
cipher_ssf33_ecb,
/*end add*/
cipher_missing /* reserved for no such supported cipher */
/* This enum must match ssl3_cipherName[] in ssl3con.c. */
} SSL3BulkCipher;
---
sslt.h modifications:
..
typedef enum {
ssl_calg_null = 0,
ssl_calg_rc4 = 1,
ssl_calg_rc2 = 2,
ssl_calg_des = 3,
ssl_calg_3des = 4,
ssl_calg_idea = 5,
ssl_calg_fortezza = 6, /* skipjack */
ssl_calg_aes = 7, /* coming soon */
/*add for ssf33 support*/
ssl_calg_ssf33_ecb = 8
/*end add*/
} SSLCipherAlgorithm;
..
---
ssl3con.c modifications:
/*add for ssf33 support*/
#define CKM_SSF33_ECB CKM_VENDOR_DEFINED+33
PK11SlotInfo *ssf33KeySlot=NULL;
/*end add*/
static const SSLCipher2Mech alg2Mech[] = {
..
/*add for ssf33 support*/
{ calg_ssf33_ecb , CKM_SSF33_ECB }
/*end add*/
/* { calg_init , (CK_MECHANISM_TYPE)0x7fffL} */
};
..
void ssl_SetSSF33Slot(PK11SlotInfo *slot) {
if (slot != NULL)
ssf33KeySlot = slot;
}
..
static SECStatus
ssl3_GenerateSessionKeys(sslSocket *ss, const PK11SymKey *pms)
{
..
/*add for ssf33 support*/
if ((ssf33KeySlot)&&(pwSpec->client.write_key->type == CKM_SSF33_ECB)) {
newKey = pwSpec->client.write_key;
pwSpec->client.write_key = pk11_CopyToSlot(ssf33KeySlot, newKey->type,
CKA_ENCRYPT, newKey);
PK11_FreeSymKey(newKey);
}
/*end add*/
pwSpec->server.write_key =
PK11_SymKeyFromHandle(slot, symKey, PK11_OriginDerive,
bulk_mechanism, returnedKeys.hServerKey, PR_TRUE, pwArg);
if (pwSpec->server.write_key == NULL ) {
goto loser; /* loser sets err */
}
/*add for ssf33 support*/
if ((ssf33KeySlot)&&(pwSpec->server.write_key->type == CKM_SSF33_ECB)) {
newKey = pwSpec->server.write_key;
pwSpec->server.write_key = pk11_CopyToSlot(ssf33KeySlot, newKey->type,
CKA_ENCRYPT, newKey);
PK11_FreeSymKey(newKey);
}
/*end add*/
}
PK11_FreeSymKey(symKey);
return SECSuccess;
loser:
if (symKey) PK11_FreeSymKey(symKey);
ssl_MapLowLevelError(SSL_ERROR_SESSION_KEY_GEN_FAILURE);
Re: NSS_SetDomesticPolicy() return 12266
> Alex, > > I think this basically means that NSS_SetDomesticPolicy() or > NSS_SetExportPolicy() is trying to flag an unimplemented cipher as > SSL_ALLOWED. You shouldn't be getting this error because the table in > sslsock.c that NSS_SetDomesticPolicy() / NSS_SetExportPolicy() get all > ciphers from contains only implemented ciphers. > > What version of NSS are you using? > > These might help: > - download the latest stable version of NSS or check it out from CVS > - print out a debugging statement in NSS_SetDomesticPolicy and > NSS_SetExportPolicy to check which suite SSL is choking on. > - e-mail me or post the complete code for your mod_ssl_startup > function. > > Out of pure curiousity, do you know about the mod_nss Apache module? > > Regards, > Peter > Peter Thanks for your suggestions. Yes, I know mod_nss Apache module, but I'm using mod_ssl on Apache now. Could you tell me where I can download mod_nss Apache module? I'm very interested on it. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Firefox https return error code -8101
Hi all. I configurated an Apache server using mod_ssl. Everything is ok when I use IE access my website by HTTPS. But using firfox,I got an 'certificate invalid or corrupt' message with an error code of -8101. I have imported the ca certificate file to firefox and checked all three boxes when importing my ca certificate,but still can't connect. Why? Thanks Alex ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: need help w tbird and pkcs11
Christian Bongiorno wrote: > Ok, I have spent over a week tweaking and toying with things and, > although I believe I am dead on, for some reason, thunderbird will not > accept the certificate on my card as valid. > > I have included the open-sc spy logs inline-- > > The last success I have show's NSS looking fro CKO_PRIVATE_KEY, which > tell it I have 1, and then it never checks the follow on attributes for > it! It almost appears as if it begins to loop on getInfoXXX > > Can someone please tell me WHAT I am missing? Compared to the logs I > have for another working card everything looks to be in order > > As an aside, I will look through the thunderbird code myself for > conditions of this error -- is their a breakdown of what needs to be > setup for acceptance? > > > Christian > *** OpenSC PKCS#11 spy * > Loaded: "C:\dev\NIST_PKCS11\bin\NIST_PKCS11.dll" > 37: C_GetAttributeValue > [in] hSession = 0x1 > [in] hObject = 0x4 > [in] pTemplate[10]: > CKA_NETSCAPE_EMAIL(Netsc) requested with 0 buffer > [out] pTemplate[10]: > CKA_NETSCAPE_EMAIL(Netsc) has size -1 > Returned: 18 CKR_ATTRIBUTE_TYPE_INVALID > > > 38: C_GetAttributeValue > [in] hSession = 0x1 > [in] hObject = 0x4 > [in] pTemplate[10]: > CKA_NETSCAPE_EMAIL(Netsc) requested with 0 buffer > [out] pTemplate[10]: CKA_NETSCAPE_EMAIL(Netsc) has size -1 > Returned: 18 CKR_ATTRIBUTE_TYPE_INVALID > > > 39: C_GetAttributeValue > [in] hSession = 0x1 > [in] hObject = 0x4 > [in] pTemplate[1]: > CKA_NETSCAPE_EMAIL(Netsc) requested with 0 buffer > [out] pTemplate[1]: > CKA_NETSCAPE_EMAIL(Netsc) has size -1 > Returned: 18 CKR_ATTRIBUTE_TYPE_INVALID > > > 40: C_GetAttributeValue > [in] hSession = 0x1 > [in] hObject = 0x4 > [in] pTemplate[1]: > CKA_NETSCAPE_EMAIL(Netsc) requested with 0 buffer > [out] pTemplate[1]: > CKA_NETSCAPE_EMAIL(Netsc) has size -1 > Returned: 18 CKR_ATTRIBUTE_TYPE_INVALID OK, this is way out of my domain, but I did notice these entries. Whether or not they have any bearing on your problem, I do not know. Perhaps asking on mozilla.dev.tech.crypto? -- Alex ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Unknown cerificate dialog
Hi My name is Alex. Im developing custom application based on mozilla engine. I have a problem, one of the features of application is to access specific web pages, some of them have certificates, some of them have certificates that Mozilla cant verify. And when this happens i see dialog tittled "Website Certified by an Unknown Authorithy" with some options to accept certificate forever , examine it etc. My project requires disabling all functionality that can lead to instalation of new certificates for security purposes. Question is - where exactly this dialog is created and how i can change it? Thanks. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Can't unwrap key into NSS in FIPS mode
Hi,
I'm working with NSS from JAVA (via JAVA 6 PKCS11 provider on RHEL 5).
My NSS database is configured for FIPS-140 mode. And I try to wrap/
unwrap AES key with RSA public/private key pair as follows:
// open NSS keystore
char[] nssDBPassword = {'f', 'i', 'p', 's', '1', '4', '0', '-',
'2'};
KeyStore ks = KeyStore.getInstance("PKCS11");
ks.load(null, nssDBPassword);
Provider p = ks.getProvider();
// generate RSA key pair
KeyPairGenerator keyPairGen = KeyPairGenerator.getInstance("RSA",
p);
KeyPair keyPair = keyPairGen.generateKeyPair();
// generate AES key
KeyGenerator keyGen = KeyGenerator.getInstance("AES", p);
keyGen.init(128);
Key rawKey = keyGen.generateKey();
System.out.println("raw Key : " + rawKey);
// wrap key
Cipher cipher = Cipher.getInstance("RSA/ECB/PKCS1Padding", p);
cipher.init(Cipher.WRAP_MODE, keyPair.getPublic());
byte[] wrappedData = cipher.wrap(rawKey);
// unwrap key
cipher = Cipher.getInstance("RSA/ECB/PKCS1Padding", p);
cipher.init(Cipher.UNWRAP_MODE, keyPair.getPrivate());
unwrappedKey = cipher.unwrap(wrappedData, "AES",
Cipher.SECRET_KEY);
// encode data
cipher = Cipher.getInstance("AES/CBC/NoPadding", p);
cipher.init(Cipher.ENCRYPT_MODE, unwrappedKey);
The wrap/unwrap code seems to work fine. But when I attempt to perform
encoding with the unwrapped key - I get the following exception
(which, as far as I understand, seems to suggest that key doesn't
reside inside NSS crypto token):
raw Key : SunPKCS11-NSScrypto AES secret key, 128 bits (id 12,
session object, sensitive, extractable)
java.security.InvalidKeyException: Could not create key
at sun.security.pkcs11.P11SecretKeyFactory.createKey
(P11SecretKeyFactory.java:226)
at sun.security.pkcs11.P11SecretKeyFactory.convertKey
(P11SecretKeyFactory.java:131)
at sun.security.pkcs11.P11Cipher.engineGetKeySize(P11Cipher.java:582)
at javax.crypto.Cipher.b(DashoA13*..)
at javax.crypto.Cipher.a(DashoA13*..)
at javax.crypto.Cipher.init(DashoA13*..)
at javax.crypto.Cipher.init(DashoA13*..)
at EncryptionTest.main(EncryptionTest.java:88)
Can anybody tell me what am I doing wrong? Or, may be, point me to
some working JAVA code that performs wrap/unwrap of the key in NSS
token?
Thank you in advance,
Alex
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Can't unwrap key into NSS in FIPS mode
> Are you sure this is not coming from the cipher.unwrap call? > If you add a line of code to print info about the unwrapped key, > does it show that key to be in the NSS token? Actually, the cipher.unwrap call passes fine, but when I print the unwrappedKey - it looks like a secretKeySpec rather than a key that resides in NSS token. But I can't figure out what am I doing wrong - 'cause I explicitly pass provider to all my cipher initializations... ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
JSS doesn't support AES key unwrapping
When I try to unwrap AES key via JSS API, I get the following
exception:
cipher = Cipher.getInstance("RSA", jssProvider);
cipher.init(Cipher.UNWRAP_MODE, wrapKeyPair.getPrivate());
Key unwrappedKey = cipher.unwrap(wrappedData, "AES",
Cipher.SECRET_KEY);
org.mozilla.jss.util.AssertionException: assertion failure!
at org.mozilla.jss.util.Assert._assert(Assert.java:58)
at org.mozilla.jss.pkcs11.PK11KeyWrapper.algFromType
(PK11KeyWrapper.java:545)
at org.mozilla.jss.pkcs11.PK11KeyWrapper.unwrapSymmetric
(PK11KeyWrapper.java:518)
at org.mozilla.jss.pkcs11.PK11KeyWrapper.unwrapSymmetric
(PK11KeyWrapper.java:484)
at
org.mozilla.jss.provider.javax.crypto.JSSCipherSpi.engineUnwrapSecret
(JSSCipherSpi.java:484)
at org.mozilla.jss.provider.javax.crypto.JSSCipherSpi.engineUnwrap
(JSSCipherSpi.java:452)
at javax.crypto.Cipher.unwrap(DashoA13*..)
at EncryptionTest.main(EncryptionTest.java:86)
The exception comes from the following code (in PK11KeyWrapper) that
clearly misses AES case:
private static Algorithm
algFromType(SymmetricKey.Type type) {
if( type == SymmetricKey.DES ) {
return EncryptionAlgorithm.DES_ECB;
} else if( type == SymmetricKey.DES3 ) {
return EncryptionAlgorithm.DES3_ECB;
} else if( type == SymmetricKey.RC4 ) {
return EncryptionAlgorithm.RC4;
} else {
Assert._assert( type == SymmetricKey.RC2 );
return EncryptionAlgorithm.RC2_CBC;
}
}
I've seen other people complaining about a similar problem.
Is this done on purpose (lack of proper code in NSS/JSS)? Or is it
some minor bug in JSS that may be easily fixed?
Thank you in advance,
Alex
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: JSS doesn't support AES key unwrapping
> oh? This is the first report of this problem that I recall seeing. Here is a similar report that I was referring to: http://groups.google.com/group/mozilla.dev.tech.crypto/browse_thread/thread/01028c36412d94bf ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
problem with JSS-based custom RMI factory
I'm trying to create a simple Java RMI application with a custom factory that uses JSS SSL classes. So I created a simple server and client factories that create SSLServerSocket and SSLSocket instances correspondingly. But when my client tries to "lookup" in the registry, the following happens: 1) the client factory is called and it creates an instance of SSLSocket 2) write() method is called on the socket 3) then it's supposed to call socketWrite() native method - but for some reason the native method lookup fails and I grab the ClassNotFound exception Now, I'm pretty sure that my envrionment (LD_LIBRARY_PATH and CLASSPATH) are set correctly and JSS is properly initialized - 'cause see it listed in current providers and I have a sample code that generates a key inside the NSS token, right before the RMI lookup code, and it works just fine. May be it has something to do with the fact that the SSLSocket code is called from RMI, and native calls can't be resolved from there? Any idea on how this can be worked around? ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: problem with JSS-based custom RMI factory
On Dec 28, 5:02 pm, alex.agra...@gmail.com wrote: > I'm trying to create a simple Java RMI application with a custom > factory that uses JSS SSL classes. So I created a simple server and > client factories that create SSLServerSocket and SSLSocket instances > correspondingly. But when my client tries to "lookup" in the registry, > the following happens: > 1) the client factory is called and it creates an instance of > SSLSocket > 2) write() method is called on the socket > 3) then it's supposed to call socketWrite() native method - but for > some reason the native method lookup fails and I grab the > ClassNotFound exception > > Now, I'm pretty sure that my envrionment (LD_LIBRARY_PATH and > CLASSPATH) are set correctly and JSS is properly initialized - 'cause > see it listed in current providers and I have a sample code that > generates a key inside the NSS token, right before the RMI lookup > code, and it works just fine. > > May be it has something to do with the fact that the SSLSocket code is > called from RMI, and native calls can't be resolved from there? Any > idea on how this can be worked around? Sorry - it was my mistake. Something is wrong with my server certificate - and as a result of that SSL handshake fails. For some reason the code fails to create SslSocketException - hence the problem that I've seen. But in any case JNI calls seem to work just fine... ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: JSS doesn't support AES key unwrapping
FYI - I submitted a patch that fixes the problem. See https://bugzilla.mozilla.org/show_bug.cgi?id=470982 for details. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
status of NSS FIPS-140 certification on SPARC Solaris 10
Hi, I wonder if someone could clear to me the status of NSS FIPS-140 certification on SPARC Solaris 10. According to https://wiki.mozilla.org/FIPS_Validation the latest certified NSS "crypto module" version is 3.11.4 (AFAIK this "crypto module" is part of NSS libraries 3.11.4 and 3.11.5) and the list of platforms includes: # Solaris 10 64-bit SPARC v9 # Solaris 10 32-bit SPARC v8+ However the issued NIST certificate mentions only one SPARC platform: # Sun Blade 2500 Workstation with UltraSPARC IIIi CPU, Sun Trusted Solaris Version 8 4/01, Extended ECC. and one Solaris 10 x86 platform: # Sun W2100z workstation with dual AMD Opteron CPUs, 64-bit Solaris 10, Extended ECC. As far as I understand, vendor and/or user may recompile FIPS- certified software on a "compatible" platform (assuming that no changes to the source code are required) and retain FIPS-140 certification. Can we use this clause to claim NSS certification on Solaris 10 SPARC platforms? Is this claim based on the certificate for Solaris 10 x86 or Solaris 8 SPARC platforms? Also what is the status of the latest FIPS-140 certification of NSS 3.12? The Wiki says that it was planned for Fall 2008 and I wonder how does it go (I see that the module is in IUT state on the NIST site). What platforms will it be certified on? Regards, Alex -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: status of NSS FIPS-140 certification on SPARC Solaris 10
Thank you. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
JSS: How to load symmetric key from NSS DB?
I wonder how is it possible to load symmetric key that is stored
inside the NSS DB via JSS API? I tried using KeyStore JCA class (as in
org.mozilla.jss.tests.KeyStoreTest example):
KeyStore ks = KeyStore.getInstance("Mozilla-JSS");
but it turns out that JSSProvider doesn't register JSSKeyStoreSpi
class at all and therefore "Mozilla-JSS" instance of KeyStore doesn't
exist.
I tried fixing this by adding the following line to JSSProvider class:
put("KeyStore.Mozilla-JSS",
"org.mozilla.jss.provider.java.security.JSSKeyStoreSpi");
But even though "getKey" API seemed to work fine, I got the following
exception when trying to use this key to init the cipher:
encryptCipher.init(Cipher.ENCRYPT_MODE, key, params);
# An unexpected error has been detected by Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x19ea4930,
pid=17900, tid=10928
#
# Java VM: Java HotSpot(TM) Client VM (11.2-b01 mixed mode windows-
x86)
# Problematic frame:
# C [nss3.dll+0x34930]
#
# An error report file with more information is saved as:
# D:\projects\yevgeniyg_EMS_5.8\TG1000\EMS\hs_err_pid17900.log
#
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native
code.
# See problematic frame for where to report the bug.
#
So I wonder if there is some way to load symmetric key stored in the
NSS DB via JCA API?
I found the similar question in this newsgroup that is almost 2 years
old:
http://groups.google.com/group/mozilla.dev.tech.crypto/browse_thread/thread/3102368d651d5cb1/92b48da59a16a2cc?lnk=gst&q=jss+keystore#92b48da59a16a2cc
- and it seems to suggest using Sun PKCS11 provider with NSS instead.
Unfortunately AFAIK one can not mix Sun PKCS11 NSS provider with JSS
in the same code - and I'm using JSS API for the rest of my
application (due to the limitations in Sun PKCS11 NSS provider) - so
this doesn't seem to be a valid alternative to me...
Thank you in advance,
Alex Agranov
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Thunderbird can decrypt without private key?
? 2010/11/10 Robert Relyea > On 11/10/2010 05:34 AM, Matej Kurpel wrote: > > Hello, > > I am implementing a PKCS#11 module for Thunderbird and I have stuck > > upon a weird behavior of Thunderbird. Let me explain: > > For the purposes of testing, I have created a second gmail account. I > > have also generated the keys and certificate for this account but only > > imported its certificate into Thunderbird (under the "People" tab in > > Certificate Manager) - I did that in order to be able to send > > encrypted messages from my primary account to this secondary account. > > I have my certificate and private key (for the primary account) in my > > token and all is properly configured in Thunderbird. > > Now, when I send an encrypted e-mail from my primary account to my > > secondary account and then try to read it (when it arrives), > > Thunderbird is able to decrypt it for me. I don't understand why, > > shouldn't that fail? > It doesn't fail because S/MIME encrypts the message to multiple > recipients. Each recipient's public key is used to wrap the symmetric > session key that the mail is encrypted with. S/MIME doesn't encode the > email address of the recipient, only a pointer to the key used (either a > subject key id or the subject/issuer of the certificate used to encrypt > the key). When decoding an S/MIME message, the client looks for any key > that it can use to decrypt the message. In your test case, it's the key > from your primary account, since the sender is also an implicit > recipient (the message is written into the 'Sent' folder, and the sender > needs to be able to read it). > > If you delete your sender's private key (after backing it up, of > course), you will find you won't be able to read the message. > > > I didn't give it the private key for the secondary account anywhere. > > From the pkcs11-spy log I can see it's calling C_DecryptInit and > > C_Decrypt as follows: > > > > > > 66: C_DecryptInit > > [in] hSession = 0x2 > > pMechanism->type=CKM_RSA_PKCS > > [in] hKey = 0x2 > > Returned: 0 CKR_OK > > > > > > 67: C_Decrypt > > [in] hSession = 0x2 > > [in] pEncryptedData[ulEncryptedDataLen] [size : 0x80 (128)] > > 4559BE33 DE12B7F1 72909126 F9F16537 8638661F 588BBCDE 2B8E2180 > > BC0E83BA > > AC1A26C0 67A25DF0 7560B64F E3E726A5 09640A4E 47540E4A D5FE2A76 > > 2116E61E > > 783EC37A 5600ED67 E42988E5 D419AC4E 70395E7F 1D0FCA66 70049230 > > D61E698F > > F6DDB51B EC79FD78 68B880F6 80A3748E F874EBA9 A672C251 003B0339 > > E7D8384E > > [out] pData[*pulDataLen] [size : 0x18 (24)] > > 673DB607 4ABCB3E0 431A9E0D 1991BC1C DCBC0208 70076D8C > > Returned: 0 CKR_OK > > It's using the sender's private key. If the code is calling > C_DecryptInit it means it has found a private key that it thinks should > work on the blob that it is trying to decrypt. > > What I have learned from this mailing list in the past is that > > Thunderbird is trying to implement key unwrapping by calling > > C_DecryptInit and C_Decrypt (and apparently this is what's actually > > happening). However, for the unwrapping, it should use the private key > > for the secondary account which it doesn't have, right? Instead, it > > uses the private key for the primary account (hKey = 0x2) and, > > surprisingly, succeedes...? > Yup. that's because the primary account was the sender. > > Please shed some light on this for me, if you know why it behaves like > > this. > > > > M. Kurpel > > > > -- > dev-tech-crypto mailing list > dev-tech-crypto@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-tech-crypto > -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Security implications for TLS validation post handshake
Hi Gregory, Using PROTOCOL_SSLv23 with OP_NO_SSLv2 | OP_NO_SSL3 | OP_NO_TLSv1 | OP_NO_TLSv1_1 is the correct way to do things in Python (of all versions) -- as you note the OP_NO_TLSv1_1/1_2 constants aren't available in older Pythons though. Luckily (unluckily?) these constants are really just integers we directly expose from OpenSSL, so it's safe to just hardcode the integer values, I don't believe OpenSSL has ever changed them. (If you're feeling particularly paranoid you can check that the OpenSSL version matches particular ABIs you've checked and only use the hardcoded values there). A bit ugly, yes, but should work fine. Ciphersuites are a slightly more interesting case. The biggest issue I see with sending a very liberal ClientHello and then erroring out based on what's negotiated is that it fails more often than necessary. Specifically, it fails whenever the server prioritizes accepting something nonsensical from the client. Unfortunately tons of servers have silly configurations; where they support both good and bad ciphers, and prioritize the bad ones! Alex On Wed, Oct 18, 2017 at 5:27 AM, Gregory Szorc wrote: > Context: > > Python has a long and sad history with regards to getting connection > security right. Modern versions of Python (>=2.7.9 and >=3.6) have a vastly > better story. But software often needs to handle what happens when running > on older versions of Python in the wild or else connection security could > be compromised. I'm trying to understand the security implications of the > interaction between Python <2.7.9 and TLS so I don't inadvertently roll out > insecure software. > > The way you specify the desired TLS protocol version (which is heavily > inspired by OpenSSL's API) is to pass a protocol constant along with some > more options to control ciphers, protocol options (like compression), etc. > If you want to require TLS 1.2+, you use SSLv23 and then mask out older > protocols. e.g. ssl.OP_NO_SSLv2 | ssl.OP_NO_SSLv3 | ssl.OP_NO_TLSv1 | > ssl.OP_NO_TLSv1_1. > > Python versions before 2.7.9 lacked controls necessary to ensure optimal > security. For example, Python didn't expose constants to force TLS versions > >1.0. Instead, you had to use PROTOCOL_TLSv1 (the latest available > constant) and force TLS 1.0. Or, you used SSLv23 (masking out SSL v2 and v3 > of course) and hoped the underlying crypto library can negotiate TLS >1.0. > > The Problem: > > I'm very naive about how TLS libraries are implemented and how the TLS > handshake works. But it seems to me that software establishing secure > connections can generally perform pre or post filtering. In > "pre-filtering," the ClientHello message only advertises ciphers/protocols > that we want to use. In "post-filtering," you advertise a more liberal list > of ciphers and depending on the negotiation results/security, you continue > or drop the connection. > > Again, I'm naive, but it feels like pre-filtering is better because it > eliminates surface area for e.g. downgrade attacks. However - and this is > where the problem resides - Python <2.7.9 doesn't exactly give you the > requisite tools for adequate pre-filtering. Since the constants aren't > there, you have to use PROTOCOL_SSLv23 and "hope" that a TLS >1.0 > connection is established. > > Question: > > Python exposes the negotiated TLS protocol version and cipher info post TLS > handshake (results of OpenSSL's SSL_get_version() and > SSL_get_current_cipher() functions). So it is possible to examine these > values to determine whether to proceed with the connection. My question is: > what are the dangers or concerns in doing so? I'm assuming there's a > surface area of downgrade-type attacks in play. But I'm not sure the > specifics. > > e.g. on Python <2.7.9, the best we can do is use PROTOCOL_SSLv23 and "hope" > the underlying crypto library is able to negotiate TLS >1.0. But this will > advertise protocols and ciphers for TLS 1.0+ in ClientHello. I don't think > this is ideal: I think I'd prefer to not advertise client support for TLS > 1.0 (and even 1.1) support at all if there is no intent on speaking these > older (and known vulnerable) protocols. > > If you aren't able to limit the advertisement of TLS 1.0 and 1.1 protocols > from the client, is it safe to validate the TLS-level security from > negotiated protocol and cipher info? Is the TLS protocol version itself > sufficient or does it need to be supplemented with e.g. a "safe" list of > ciphers? > -- > dev-tech-crypto mailing list > dev-tech-crypto@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-tech-crypto > -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
NSS v3.52 and TLSv1.3's Post-Handshake Authentication -- completion notification?
Greetings folks,
With moz-bz#1561637 having landed upstream (and subsequently v3.52 being
shipped downstream in Fedora), I've been testing JSS's SSLEngine with
TLSv1.3 again.
One of the issues I've had is there's no good indicator for either
key-exchange or post-handshake auth being started or completed by either
party (client or server).
SSLEngine (in Java) for those unaware has (roughly) the following semantics:
- After beginHandshake() has been called, handshake status stays in
NEED_WRAP, NEED_UNWRAP, or NEED_TASK until the handshake is
complete. Then it moves to FINISHED and finally to
NOT_HANDSHAKING.
- beginHandshake() is called implicitly the first time from wrap()
and unwrap().
- If certs are required after the initial handshake (such as via PHA in
TLSv1.3 or a full re-handshake when available in TLSv1.2 and earlier),
beginHandshake() semantics apply again.
The last requirement is the "hard" one under TLSv1.3.
I've set a SSL_HandshakeCallback() that informs me when the initial
handshake is completed. This works fine for both client and
server-initiated re-handshakes under TLSv1.2. However, this callback
is never executed under TLSv1.3 (in part) because PHA and re-key requests
aren't strictly a new handshake.
So what I ask are:
- Is there a reliable way to tell (as both a client and server) when
PHA/rekey requests have started?
- Is there a reliable way to tell (as both a client and server) when
PHA/rekey requests have completed?
- Is there a reliable way to tell (as both a client and server) when
a handshake has been initiated by the other party (on TLS < 1.2)?
I'm fine living without 1 and 3, but 2 is the more of an issue for me.
I'd be happy to submit the code changes to trigger SSL_HandshakeCallback
via TLSv1.3 PHA/re-key requests -- but I'm not sure if that'd technically
conform to the function's documentation:
> /*
> ** Set the callback that gets called when a TLS handshake is complete. The
> ** handshake callback is called after verifying the peer's Finished message
> and
> ** before processing incoming application data.
> **
> ** For the initial handshake: If the handshake false started (see
> ** SSL_ENABLE_FALSE_START), then application data may already have been sent
> ** before the handshake callback is called. If we did not false start then the
> ** callback will get called before any application data is sent.
> */
> typedef void(PR_CALLBACK *SSLHandshakeCallback)(PRFileDesc *fd,
> void *client_data);
> SSL_IMPORT SECStatus SSL_HandshakeCallback(PRFileDesc *fd,
>SSLHandshakeCallback cb, void
> *client_data);
It might be surprising behavior? But on the other hand, these two do
kinda replace the (insecure) second handshake. Perhaps gating it behind
an option flag would suffice though (SSL_HANDSHAKE_CALLBACK_FOR_PHA or
some such)?
When looking at the other SSL_SendCertificateRequest experimental API
docs, it does say AuthCertificateComplete is called on the server side:
> /* This function allows a server application to trigger
> * re-authentication (TLS 1.3 only) after handshake.
> *
> * This function will cause a CertificateRequest message to be sent by
> * a server. This can be called once at a time, and is not allowed
> * until an answer is received.
> *
> * This function is not allowed for use with DTLS or when external
> * PSK authentication has been negotiated. SECFailure is returned
> * in both cases.
> *
> * The AuthCertificateCallback is called when the answer is received.
> * If the answer is accepted by the server, the value returned by
> * SSL_PeerCertificate() is replaced. If you need to remember all the
> * certificates, you will need to call SSL_PeerCertificate() and save
> * what you get before calling this.
> *
> * If the AuthCertificateCallback returns SECFailure, the connection
> * is aborted.
> */
> #define SSL_SendCertificateRequest(fd) \
> SSL_EXPERIMENTAL_API("SSL_SendCertificateRequest", \
> (PRFileDesc * _fd), \
> (fd))
But this doesn't help on the client side. Additionally, my situation with
AuthCertificateCallback is... complicated (it is either not explicitly set
to use the default NSS value, set to something with no knowledge of my
SSLEngine, or something with knowledge of the SSLEngine) -- so I'm not
sure I like that design.
Thoughts? I feel like I might be missing something.
- Alex
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: NSS v3.52 and TLSv1.3's Post-Handshake Authentication -- completion notification?
Thanks Martin and Daiki! - Original Message - > From: "Martin Thomson" > To: "Daiki Ueno" > Cc: "mozilla's crypto code discussion list" > > Sent: Tuesday, July 7, 2020 10:26:07 PM > Subject: Re: NSS v3.52 and TLSv1.3's Post-Handshake Authentication -- > completion notification? > > On Wed, Jul 8, 2020 at 2:36 AM Daiki Ueno wrote: > > > > Martin Thomson writes: > > > > > I think that we considered this when we first landed this code, but > > > deferred adding any callbacks until it was clear what the right answer > > > was. As you say, you get the callback, but you might not if the > > > request is rejected. > > > > I think that is about the server side. On the client side, it seems > > even harder to detect the completion, because there will be no > > indication of acceptance until the next application data is sent. > > Fair point, but we have never had a way to indicate that you consider > your peer to be authenticated as "X". It's down to individual > authorization decisions to reflect whatever opinion you have formed. > For instance, a 403 response in HTTP might provide some more > information. (I seem to have lost Daiki's reply) I don't care too much (from a client perspective) whether or not our credentials were accepted. If they weren't, the worst that will happen is I'll get an alert later and everything will close down anyways -- or, the server will ignore them (passing the failure to the application) and I'm left wondering why it asked for credentials anyways. Perhaps the application will reject the lack of credentials and close the connection itself, but with a pretty application-level error message. Either way, my working assumption is that if the server doesn't like the credentials, it'll at worst close the connection. At best, it'll prompt me for new credentials again. (It'll probably get the same answer, but that's a different discussion). "meh"? So on the client side, I'd be fine triggering the alert once the outbound FINISHED message is written to the wire. The same holds on the server: I'd always trigger once the AuthCertificateCallback is complete, regardless of its outcome (accepted or not). I've not checked NSS's behavior here: if PHA is requested, and the cert fails to verify, does NSS return the error as a fatal alert? Or is it up to the application code whether a failed PHA gives a fatal alert? The doc text for SendCertificateRequest seems to indicate that no fatal alert is sent in the event of invalid certificates, which is fine by me. I think that this last suggestion differs from the triggering during regular handshakes? If the handshake fails, the handshake callback won't trigger... We failed to get new, valid credentials, but--if the application needs to know that we negotiated new credentials, it can always save the previous PeerCertificate() prior to executing the PHA request and then check it in the callback and act accordingly. My 2c, - Alex -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
