Re: Announcing Mozilla::PKIX, a New Certificate Verification Library
Please file a new bug here: https://bugzilla.mozilla.org/enter_bug.cgi?product=Corecomponent=Security%3A%20PSM It would be helpful if you attached the certificate the device is sending. On 07/01/2015 08:15 AM, pavel.shlyon...@gmail.com wrote: Hello guys. Just updated firmware in my Sonicwall TZ210W Now unable to sign in to management page. Secure Connection Failed The page you are trying to view cannot be shown because the authenticity of the received data could not be verified. Please contact the website owners to inform them of this problem. What is the workaround to fix this? Certificate information. HTTPS Management Certificate Certificate Issuer: /C=US/ST=California/L=Sunnyvale/O=HTTPS Management Certificate for SonicWALL (self-signed)/OU=HTTPS Management Certificate for SonicWALL (self-signed)/CN=192.168.168.168 Subject Distinguished Name: /C=US/ST=California/L=Sunnyvale/O=HTTPS Management Certificate for SonicWALL (self-signed)/OU=HTTPS Management C ertificate for SonicWALL (self-signed)/CN=192.168.168.168 Certificate Serial Number: 4F50DAE9 Valid from: Jan 1 00:00:01 1970 GMT Expires On: Jan 19 03:14:07 2038 GMT Status: Not Verified - Self-signed signature.asc Description: OpenPGP digital signature -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Announcing Mozilla::PKIX, a New Certificate Verification Library
Hello guys. Just updated firmware in my Sonicwall TZ210W Now unable to sign in to management page. Secure Connection Failed The page you are trying to view cannot be shown because the authenticity of the received data could not be verified. Please contact the website owners to inform them of this problem. What is the workaround to fix this? Certificate information. HTTPS Management Certificate Certificate Issuer: /C=US/ST=California/L=Sunnyvale/O=HTTPS Management Certificate for SonicWALL (self-signed)/OU=HTTPS Management Certificate for SonicWALL (self-signed)/CN=192.168.168.168 Subject Distinguished Name: /C=US/ST=California/L=Sunnyvale/O=HTTPS Management Certificate for SonicWALL (self-signed)/OU=HTTPS Management C ertificate for SonicWALL (self-signed)/CN=192.168.168.168 Certificate Serial Number: 4F50DAE9 Valid from: Jan 1 00:00:01 1970 GMT Expires On: Jan 19 03:14:07 2038 GMT Status: Not Verified - Self-signed -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Announcing Mozilla::PKIX, a New Certificate Verification Library
On Monday, April 7, 2014 at 6:33:50 PM UTC-4, Kathleen Wilson wrote: All, We have been working on a new certificate verification library for Gecko, and would greatly appreciate it if you will test this new library and review the new code. Background NSS currently has two code paths for doing certificate verification. Classic verification has been used for verification of non-EV certificates, and libPKIX has been used for verification of EV certificates. As many of you are aware, the NSS team has wanted to replace the classic verification with libPKIX for a long time. However, the current libPKIX code was auto-translated from Java to C, and has proven to be very difficult to maintain and use. Therefore, Mozilla has created a new certificate verification library called mozilla::pkix. Request for Testing Replacing the certificate verification library can only be done after gaining sufficient confidence in the new code by having as many people and organizations test it as possible. We ask that all of you help us test this new library as described here: https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Request_for_Testing Testing Window: The mozilla::pkix certificate verification library is available for testing now in Nightly Firefox builds. We ask that you test as soon as possible, and that you complete your testing before Firefox 31 exits the Aurora branch in June. (See https://wiki.mozilla.org/RapidRelease/Calendar) Request for Code Review The more people who code review the new code, the better. So we ask all of you C++ programmers out there to review the code and let us know if you see any potential issues. https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Request_for_Code_Review We look forward to your help in testing and reviewing this new certificate verification library. Mozilla Security Engineering Team Hi, I am facing some difficulty with a particular website. I cannot log in to my college account.(my.rutgers.edu) I get these errors The page you are trying to view cannot be shown because the authenticity of the received data could not be verified. Please contact the website owners to inform them of this problem. I have not changed any setting. It was working fine before I updated firefox. Please let me know what should I do to get rid of the problem. Thanks in advance -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Announcing Mozilla::PKIX, a New Certificate Verification Library
my.rutgers.edu only offers a single cipher suite (TLS_RSA_WITH_RC4_128_SHA) and is TLS 1.1/1.2 intolerant [0]. We essentially disabled RC4 and insecure fallback to TLS 1.0 by default, which is why you're unable to connect with recent (i.e. pre-release) versions of Firefox. I filed bug 1139065 [1] as a tech evangelism bug to hopefully reach out to the server administrators so they can fix their site. In the meantime, if you set the pref security.tls.insecure_fallback_hosts to my.rutgers.edu in about:config, it should work. Cheers, David [0] https://www.ssllabs.com/ssltest/analyze.html?d=my.rutgers.edu [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1139065 On 03/02/2015 10:47 AM, 1992.cha...@gmail.com wrote: Hi, I am facing some difficulty with a particular website. I cannot log in to my college account.(my.rutgers.edu) I get these errors The page you are trying to view cannot be shown because the authenticity of the received data could not be verified. Please contact the website owners to inform them of this problem. I have not changed any setting. It was working fine before I updated firefox. Please let me know what should I do to get rid of the problem. Thanks in advance -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Announcing Mozilla::PKIX, a New Certificate Verification Library
On Thursday, October 16, 2014 3:04:59 PM UTC-5, treb...@gmail.com wrote: On Monday, April 7, 2014 6:33:50 PM UTC-4, Kathleen Wilson wrote: All, We have been working on a new certificate verification library for Gecko, and would greatly appreciate it if you will test this new library and review the new code. Background NSS currently has two code paths for doing certificate verification. Classic verification has been used for verification of non-EV certificates, and libPKIX has been used for verification of EV certificates. As many of you are aware, the NSS team has wanted to replace the classic verification with libPKIX for a long time. However, the current libPKIX code was auto-translated from Java to C, and has proven to be very difficult to maintain and use. Therefore, Mozilla has created a new certificate verification library called mozilla::pkix. Request for Testing Replacing the certificate verification library can only be done after gaining sufficient confidence in the new code by having as many people and organizations test it as possible. We ask that all of you help us test this new library as described here: https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Request_for_Testing Testing Window: The mozilla::pkix certificate verification library is available for testing now in Nightly Firefox builds. We ask that you test as soon as possible, and that you complete your testing before Firefox 31 exits the Aurora branch in June. (See https://wiki.mozilla.org/RapidRelease/Calendar) Request for Code Review The more people who code review the new code, the better. So we ask all of you C++ programmers out there to review the code and let us know if you see any potential issues. https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Request_for_Code_Review We look forward to your help in testing and reviewing this new certificate verification library. Mozilla Security Engineering Team Mozilla::pkix includes some changes in support of current best practices and policies, as listed below. If you notice an issue due to any of these changes, please feel free to let us know. However, we believe that in most cases, the simplest resolution will be to update the SSL certificate in your webserver. YOU F**KTARDS.. SOMETIMES WE HAVE ABSOLUTELY ZERO F**KING CONTROL OVER THE SSL CERT PRESENTED.. WE **know** IT SHOULD BE TRUSTED BECAUSE ITS AN INTERNAL F**KING DEVICE, AND DON'T GIVE ONE FLYING F**K IF THE CERT IS VALID OR NOT.. WE **SHOULD** BE ALLOWED REGARDLESS OF THE F**KING CAUSE, TO ADD AN EXCEPTION.. TAKE THE SAME F**KING URL TO ANY OTHER BROWSER, AND AT WORST YOU GET CHROME WHICH NOW WON'T REMEMBER USER/PASS COMBOS TO GET INTO THOSE SITES BUT IT STILL F**KING LETS YOU GET TO THE GOD DAMNED F**KING SITE! WHY IS IT THAT YOU SMART A** F**KERS CAN'T UNDERSTAND YOU **CAN NOT FORCE THIS ON PEOPLE** YOU **MUST** ALLOW THEM TO ADD AN EXCEPTION EVEN IF TEMPORARY! OTHERWISE BY NOT ALLOWING US TO DO SO YOU FORCE US TO USE ANOTHER BROWSER.. FOR SOME OF US AS PART OF OUR JOB.. AND WHAT THEN IS THE POINT OF HAVING FIREFOX IF YOU CAN'T USE IT TO DO YOUR F**KING WORK? F**KTARD DEVELOPERS you think you're so smart, you think you know everything and that because YOU think vendors of broken hardware should be forced to fix.. or what.. buy something new? ... F U devs.. you fix this.. or see people abandon you and loose what little cred you had in the browser war! I agree with the opinion this user is trying to get across. We end users must have an option to completely circumvent security measures when we know a connection is trusted. Otherwise, like the poster indicated, we have to ditch Firefox and use a browser that gives us that capability. We, the end users, don't want to make a statement of how global security practices should theoretically work. We want to use a browser that we have control of and can use as a tool to accomplish a task. Removing some of the functionality of the browser and forcing us into a rigid security model only makes us install a second browser. Over time, I can imagine that the second browser would usurp Firefox's position as Preferred browser. Just an opinion, from an end-user. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Announcing Mozilla::PKIX, a New Certificate Verification Library
On Nov 5, 2014, at 3:43 PM, crodenb...@gmail.com wrote: On Thursday, October 16, 2014 3:04:59 PM UTC-5, treb...@gmail.com wrote: On Monday, April 7, 2014 6:33:50 PM UTC-4, Kathleen Wilson wrote: All, We have been working on a new certificate verification library for Gecko, and would greatly appreciate it if you will test this new library and review the new code. Background NSS currently has two code paths for doing certificate verification. Classic verification has been used for verification of non-EV certificates, and libPKIX has been used for verification of EV certificates. As many of you are aware, the NSS team has wanted to replace the classic verification with libPKIX for a long time. However, the current libPKIX code was auto-translated from Java to C, and has proven to be very difficult to maintain and use. Therefore, Mozilla has created a new certificate verification library called mozilla::pkix. Request for Testing Replacing the certificate verification library can only be done after gaining sufficient confidence in the new code by having as many people and organizations test it as possible. We ask that all of you help us test this new library as described here: https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Request_for_Testing Testing Window: The mozilla::pkix certificate verification library is available for testing now in Nightly Firefox builds. We ask that you test as soon as possible, and that you complete your testing before Firefox 31 exits the Aurora branch in June. (See https://wiki.mozilla.org/RapidRelease/Calendar) Request for Code Review The more people who code review the new code, the better. So we ask all of you C++ programmers out there to review the code and let us know if you see any potential issues. https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Request_for_Code_Review We look forward to your help in testing and reviewing this new certificate verification library. Mozilla Security Engineering Team Mozilla::pkix includes some changes in support of current best practices and policies, as listed below. If you notice an issue due to any of these changes, please feel free to let us know. However, we believe that in most cases, the simplest resolution will be to update the SSL certificate in your webserver. YOU F**KTARDS.. SOMETIMES WE HAVE ABSOLUTELY ZERO F**KING CONTROL OVER THE SSL CERT PRESENTED.. WE **know** IT SHOULD BE TRUSTED BECAUSE ITS AN INTERNAL F**KING DEVICE, AND DON'T GIVE ONE FLYING F**K IF THE CERT IS VALID OR NOT.. WE **SHOULD** BE ALLOWED REGARDLESS OF THE F**KING CAUSE, TO ADD AN EXCEPTION.. TAKE THE SAME F**KING URL TO ANY OTHER BROWSER, AND AT WORST YOU GET CHROME WHICH NOW WON'T REMEMBER USER/PASS COMBOS TO GET INTO THOSE SITES BUT IT STILL F**KING LETS YOU GET TO THE GOD DAMNED F**KING SITE! WHY IS IT THAT YOU SMART A** F**KERS CAN'T UNDERSTAND YOU **CAN NOT FORCE THIS ON PEOPLE** YOU **MUST** ALLOW THEM TO ADD AN EXCEPTION EVEN IF TEMPORARY! OTHERWISE BY NOT ALLOWING US TO DO SO YOU FORCE US TO USE ANOTHER BROWSER.. FOR SOME OF US AS PART OF OUR JOB.. AND WHAT THEN IS THE POINT OF HAVING FIREFOX IF YOU CAN'T USE IT TO DO YOUR F**KING WORK? F**KTARD DEVELOPERS you think you're so smart, you think you know everything and that because YOU think vendors of broken hardware should be forced to fix.. or what.. buy something new? ... F U devs.. you fix this.. or see people abandon you and loose what little cred you had in the browser war! I agree with the opinion this user is trying to get across. We end users must have an option to completely circumvent security measures when we know a connection is trusted. Otherwise, like the poster indicated, we have to ditch Firefox and use a browser that gives us that capability. We, the end users, don't want to make a statement of how global security practices should theoretically work. We want to use a browser that we have control of and can use as a tool to accomplish a task. Removing some of the functionality of the browser and forcing us into a rigid security model only makes us install a second browser. Over time, I can imagine that the second browser would usurp Firefox's position as Preferred browser. Just an opinion, from an end-user. Just to let you know, we hear you. We're having some internal discussions about how to better balance the considerations here. On the one hand, for most people in most situations, the browser needs to make an intelligent choice on behalf of the user. Sometimes, that's going to involve not connecting at all. On the other hand, we also need to enable power users, who have done their homework, to get their work done. Look for some proposals here soon. --Richard -- dev-tech-crypto
Re: Announcing Mozilla::PKIX, a New Certificate Verification Library
Le jeudi 16 octobre 2014 22:04:59 UTC+2, treb...@gmail.com a écrit : [...] YOU F**KTARDS.. SOMETIMES WE HAVE ABSOLUTELY ZERO F**KING CONTROL OVER THE SSL CERT PRESENTED.. WE **know** IT SHOULD BE TRUSTED BECAUSE ITS AN INTERNAL F**KING DEVICE, AND DON'T GIVE ONE FLYING F**K IF THE CERT IS VALID OR NOT.. [...] F**KTARD DEVELOPERS you think you're so smart, you think you know everything and that because YOU think vendors of broken hardware should be forced to fix.. or what.. buy something new? ... F U devs.. you fix this.. or see people abandon you and loose what little cred you had in the browser war! All this could have been written using less capital letters and less bad words. That doesn't help your cause. Next time you're angry, find a wall and hit it, or go run outside while yelling. Then come back positive-minded. Kiss. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Announcing Mozilla::PKIX, a New Certificate Verification Library
On Monday, April 7, 2014 6:33:50 PM UTC-4, Kathleen Wilson wrote: All, We have been working on a new certificate verification library for Gecko, and would greatly appreciate it if you will test this new library and review the new code. Background NSS currently has two code paths for doing certificate verification. Classic verification has been used for verification of non-EV certificates, and libPKIX has been used for verification of EV certificates. As many of you are aware, the NSS team has wanted to replace the classic verification with libPKIX for a long time. However, the current libPKIX code was auto-translated from Java to C, and has proven to be very difficult to maintain and use. Therefore, Mozilla has created a new certificate verification library called mozilla::pkix. Request for Testing Replacing the certificate verification library can only be done after gaining sufficient confidence in the new code by having as many people and organizations test it as possible. We ask that all of you help us test this new library as described here: https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Request_for_Testing Testing Window: The mozilla::pkix certificate verification library is available for testing now in Nightly Firefox builds. We ask that you test as soon as possible, and that you complete your testing before Firefox 31 exits the Aurora branch in June. (See https://wiki.mozilla.org/RapidRelease/Calendar) Request for Code Review The more people who code review the new code, the better. So we ask all of you C++ programmers out there to review the code and let us know if you see any potential issues. https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Request_for_Code_Review We look forward to your help in testing and reviewing this new certificate verification library. Mozilla Security Engineering Team Mozilla::pkix includes some changes in support of current best practices and policies, as listed below. If you notice an issue due to any of these changes, please feel free to let us know. However, we believe that in most cases, the simplest resolution will be to update the SSL certificate in your webserver. YOU F**KTARDS.. SOMETIMES WE HAVE ABSOLUTELY ZERO F**KING CONTROL OVER THE SSL CERT PRESENTED.. WE **know** IT SHOULD BE TRUSTED BECAUSE ITS AN INTERNAL F**KING DEVICE, AND DON'T GIVE ONE FLYING F**K IF THE CERT IS VALID OR NOT.. WE **SHOULD** BE ALLOWED REGARDLESS OF THE F**KING CAUSE, TO ADD AN EXCEPTION.. TAKE THE SAME F**KING URL TO ANY OTHER BROWSER, AND AT WORST YOU GET CHROME WHICH NOW WON'T REMEMBER USER/PASS COMBOS TO GET INTO THOSE SITES BUT IT STILL F**KING LETS YOU GET TO THE GOD DAMNED F**KING SITE! WHY IS IT THAT YOU SMART A** F**KERS CAN'T UNDERSTAND YOU **CAN NOT FORCE THIS ON PEOPLE** YOU **MUST** ALLOW THEM TO ADD AN EXCEPTION EVEN IF TEMPORARY! OTHERWISE BY NOT ALLOWING US TO DO SO YOU FORCE US TO USE ANOTHER BROWSER.. FOR SOME OF US AS PART OF OUR JOB.. AND WHAT THEN IS THE POINT OF HAVING FIREFOX IF YOU CAN'T USE IT TO DO YOUR F**KING WORK? F**KTARD DEVELOPERS you think you're so smart, you think you know everything and that because YOU think vendors of broken hardware should be forced to fix.. or what.. buy something new? ... F U devs.. you fix this.. or see people abandon you and loose what little cred you had in the browser war! -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Announcing Mozilla::PKIX, a New Certificate Verification Library
I am accessing pfSense router/s that have self-generated certificates so obviously they do not validate publicly. Prior to Firefox 31 I had the security warning and had clicked through to add the certificate for a number of these routers on our internal networks. The list of certificates in Firefox then included a bunch under the name CompanyName. After upgrade to Firefox 31 it started taking a long time (15-20 seconds) to bring up the login page to these routers. During that time the CPU was running 100%. Then after login, every few minutes Firefox would use 100% CPU for a minute or 2, becoming effectively unresponsive in any tab. I tried Firefox 24, 28, 29, 30 - none of these had the symptoms. Tried Firefox 31, 32, 33 (beta) and 34 (aurora). They all had the symptoms described. Looking in pfSense forums I discovered this post - https://forum.pfsense.org/index.php?topic=82295.0 I deleted the certificates under CompanyName. Now display time for the Login page is back to normal, and Firefox CPU time is not going crazy every few minutes. Maybe there is something that can be done to help this situation? Maybe these old private certificates need to be cleaned out on upgrade? Or maybe something in the code that is going nuts trying to validate these private certificates needs to be fixed? -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Announcing Mozilla::PKIX, a New Certificate Verification Library
I am accessing pfSense router/s that have self-generated certificates so obviously they do not validate publicly. Prior to Firefox 31 I had the security warning and had clicked through to add the certificate for a number of these routers on our internal networks. The list of certificates in Firefox then included a bunch under the name CompanyName. After upgrade to Firefox 31 it started taking a long time (15-20 seconds) to bring up the login page to these routers. During that time the CPU was running 100%. Then after login, every few minutes Firefox would use 100% CPU for a minute or 2, becoming effectively unresponsive in any tab. I tried Firefox 24, 28, 29, 30 - none of these had the symptoms. Tried Firefox 31, 32, 33 (beta) and 34 (aurora). They all had the symptoms described. Looking in pfSense forums I discovered this post - https://forum.pfsense.org/index.php?topic=82295.0 - and added to it. I deleted the certificates under CompanyName. Now display time for the Login page is back to normal, and Firefox CPU time is not going crazy every few minutes. Maybe there is something that can be done to hep this situation? Maybe these old private certificates need to be cleaned out on upgrade? Or maybe something in the code that is going nuts trying to validate these private certificates needs to be fixed? -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Announcing Mozilla::PKIX, a New Certificate Verification Library
On Thu, Oct 2, 2014 at 9:03 AM, davpj...@ozemail.com.au wrote: Maybe there is something that can be done to hep this situation? Maybe these old private certificates need to be cleaned out on upgrade? Or maybe something in the code that is going nuts trying to validate these private certificates needs to be fixed? There is already a bug report about this issue: https://bugzilla.mozilla.org/show_bug.cgi?id=1056341 Cheers, Brian -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Announcing Mozilla::PKIX, a New Certificate Verification Library
On Monday, April 7, 2014 6:33:50 PM UTC-4, Kathleen Wilson wrote: All, We have been working on a new certificate verification library for Gecko, and would greatly appreciate it if you will test this new library and review the new code. Background NSS currently has two code paths for doing certificate verification. Classic verification has been used for verification of non-EV certificates, and libPKIX has been used for verification of EV certificates. As many of you are aware, the NSS team has wanted to replace the classic verification with libPKIX for a long time. However, the current libPKIX code was auto-translated from Java to C, and has proven to be very difficult to maintain and use. Therefore, Mozilla has created a new certificate verification library called mozilla::pkix. Request for Testing Replacing the certificate verification library can only be done after gaining sufficient confidence in the new code by having as many people and organizations test it as possible. We ask that all of you help us test this new library as described here: https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Request_for_Testing Testing Window: The mozilla::pkix certificate verification library is available for testing now in Nightly Firefox builds. We ask that you test as soon as possible, and that you complete your testing before Firefox 31 exits the Aurora branch in June. (See https://wiki.mozilla.org/RapidRelease/Calendar) Request for Code Review The more people who code review the new code, the better. So we ask all of you C++ programmers out there to review the code and let us know if you see any potential issues. https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Request_for_Code_Review We look forward to your help in testing and reviewing this new certificate verification library. Mozilla Security Engineering Team We use self-signed certificates for our DEV, TEST, and Staging environments and now we cannot access the sites via Firefox. When i change the the about:config mozilla::pkix attribute to false, we get a 404 error. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Announcing Mozilla::PKIX, a New Certificate Verification Library
Brian, I just ran into the Netscape Cert Type critical extension issue with an internal cert. Is there an override setting to allow this cert to work in Firefox still ? IMO, the Firefox behavior is particularly bad, because Firefox won't even let you look at the cert details to see what the problematic extension is. I had to look at the cert details in Chrome (which still uses libpkix) . Julien -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Announcing Mozilla::PKIX, a New Certificate Verification Library
Hi Julien, Currently there is no way to override that behavior. We're working on improving the situation in bug 1009161. See also bug 1054368 regarding a way to view the certificate for non-overridable errors. If you can get in touch with whoever administers the internal certificates, I would encourage them to take a look at https://wiki.mozilla.org/SecurityEngineering/x509Certs for information on how to create a certificate hierarchy that is compatible with RFC 5280. David On 08/15/2014 12:47 AM, Julien Pierre wrote: Brian, I just ran into the Netscape Cert Type critical extension issue with an internal cert. Is there an override setting to allow this cert to work in Firefox still ? IMO, the Firefox behavior is particularly bad, because Firefox won't even let you look at the cert details to see what the problematic extension is. I had to look at the cert details in Chrome (which still uses libpkix) . Julien -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Announcing Mozilla::PKIX, a New Certificate Verification Library
On Monday, April 7, 2014 6:33:50 PM UTC-4, Kathleen Wilson wrote: All, We have been working on a new certificate verification library for Gecko, and would greatly appreciate it if you will test this new library and review the new code. Background NSS currently has two code paths for doing certificate verification. Classic verification has been used for verification of non-EV certificates, and libPKIX has been used for verification of EV certificates. As many of you are aware, the NSS team has wanted to replace the classic verification with libPKIX for a long time. However, the current libPKIX code was auto-translated from Java to C, and has proven to be very difficult to maintain and use. Therefore, Mozilla has created a new certificate verification library called mozilla::pkix. Request for Testing Replacing the certificate verification library can only be done after gaining sufficient confidence in the new code by having as many people and organizations test it as possible. We ask that all of you help us test this new library as described here: https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Request_for_Testing Testing Window: The mozilla::pkix certificate verification library is available for testing now in Nightly Firefox builds. We ask that you test as soon as possible, and that you complete your testing before Firefox 31 exits the Aurora branch in June. (See https://wiki.mozilla.org/RapidRelease/Calendar) Request for Code Review The more people who code review the new code, the better. So we ask all of you C++ programmers out there to review the code and let us know if you see any potential issues. https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Request_for_Code_Review We look forward to your help in testing and reviewing this new certificate verification library. Mozilla Security Engineering Team Yup - having a problem. Novell ZENworks optionally uses an internal CA and with FF 31 I can no longer connect to the management console or any of the other web services. I'll try turning off the new CA checker to see if that works. I like the idea of better security, but you just pissed off a lot of my customers. Bruce McDowell McDowell Consulting LLC br...@consultbruce.com -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Announcing Mozilla::PKIX, a New Certificate Verification Library
On Aug 5, 2014, at 1:25 PM, Brian Smith br...@briansmith.org wrote: On Tue, Aug 5, 2014 at 9:51 AM, mjle...@gmail.com wrote: Since updating to 31, I have not been able to log into a self signed web page: Secure Connection Failed An error occurred during a connection to taiserver:444. Certificate key usage inadequate for attempted operation. (Error code: sec_error_inadequate_key_usage) How do I get this corrected? Please file a bug at https://bugzilla.mozilla.org/enter_bug.cgi?product=Corecomponent=Security:%20PSM (Product: Core, Component: PSM) and attach the certificate in question to the bug report. Of course, it sounds likely to be related to the new key usage checks listed in the relevant wiki page: https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Behavior_Changes You might check to see if that's the case before filing a bug. --Richard Cheers, Brian -- 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: Announcing Mozilla::PKIX, a New Certificate Verification Library
Since updating to 31, I have not been able to log into a self signed web page: Secure Connection Failed An error occurred during a connection to taiserver:444. Certificate key usage inadequate for attempted operation. (Error code: sec_error_inadequate_key_usage) How do I get this corrected? Mike -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Announcing Mozilla::PKIX, a New Certificate Verification Library
On Tue, Aug 5, 2014 at 9:51 AM, mjle...@gmail.com wrote: Since updating to 31, I have not been able to log into a self signed web page: Secure Connection Failed An error occurred during a connection to taiserver:444. Certificate key usage inadequate for attempted operation. (Error code: sec_error_inadequate_key_usage) How do I get this corrected? Please file a bug at https://bugzilla.mozilla.org/enter_bug.cgi?product=Corecomponent=Security:%20PSM (Product: Core, Component: PSM) and attach the certificate in question to the bug report. Cheers, Brian -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Announcing Mozilla::PKIX, a New Certificate Verification Library
On 08/02/2014 08:39 AM, colinhogg...@gmail.com wrote: Since the latest update 3 days ago I have been unable to log in to any of my Netgear equipment using Firefox. I get the error: (Error code: sec_error_extension_value_invalid. I can access my equipment using Explorer so I can only assume it might be something to do with this access list. That sounds like bug 101 ( https://bugzilla.mozilla.org/show_bug.cgi?id=101 ). -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Announcing Mozilla::PKIX, a New Certificate Verification Library
Team After upgrade to Firefox 31, I am not able to request any https link through my firewall and getting certificate failure. I tried re-import of firewall certificate but in vein. Please suggest. On Tuesday, 8 April 2014 04:03:50 UTC+5:30, Kathleen Wilson wrote: All, We have been working on a new certificate verification library for Gecko, and would greatly appreciate it if you will test this new library and review the new code. Background NSS currently has two code paths for doing certificate verification. Classic verification has been used for verification of non-EV certificates, and libPKIX has been used for verification of EV certificates. As many of you are aware, the NSS team has wanted to replace the classic verification with libPKIX for a long time. However, the current libPKIX code was auto-translated from Java to C, and has proven to be very difficult to maintain and use. Therefore, Mozilla has created a new certificate verification library called mozilla::pkix. Request for Testing Replacing the certificate verification library can only be done after gaining sufficient confidence in the new code by having as many people and organizations test it as possible. We ask that all of you help us test this new library as described here: https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Request_for_Testing Testing Window: The mozilla::pkix certificate verification library is available for testing now in Nightly Firefox builds. We ask that you test as soon as possible, and that you complete your testing before Firefox 31 exits the Aurora branch in June. (See https://wiki.mozilla.org/RapidRelease/Calendar) Request for Code Review The more people who code review the new code, the better. So we ask all of you C++ programmers out there to review the code and let us know if you see any potential issues. https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Request_for_Code_Review We look forward to your help in testing and reviewing this new certificate verification library. Mozilla Security Engineering Team -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Announcing Mozilla::PKIX, a New Certificate Verification Library
Hi Jugal, For issues with mozilla::pkix, the following might be helpful: https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Behavior_Changes If that doesn't resolve the issue, please file a bug here: https://bugzilla.mozilla.org/enter_bug.cgi?product=Corecomponent=Security:%20PSMshort_desc=%28mozilla::pkix%29 It would be helpful if you could include either a link to a publicly-accessible site that exhibits the problem or post a copy of the certificate chain that is problematic. The error code (something like sec_error_...) would also be helpful. Thanks, David On 07/24/2014 09:26 PM, jugal.sa...@gmail.com wrote: Team After upgrade to Firefox 31, I am not able to request any https link through my firewall and getting certificate failure. I tried re-import of firewall certificate but in vein. Please suggest. On Tuesday, 8 April 2014 04:03:50 UTC+5:30, Kathleen Wilson wrote: All, We have been working on a new certificate verification library for Gecko, and would greatly appreciate it if you will test this new library and review the new code. Background NSS currently has two code paths for doing certificate verification. Classic verification has been used for verification of non-EV certificates, and libPKIX has been used for verification of EV certificates. As many of you are aware, the NSS team has wanted to replace the classic verification with libPKIX for a long time. However, the current libPKIX code was auto-translated from Java to C, and has proven to be very difficult to maintain and use. Therefore, Mozilla has created a new certificate verification library called mozilla::pkix. Request for Testing Replacing the certificate verification library can only be done after gaining sufficient confidence in the new code by having as many people and organizations test it as possible. We ask that all of you help us test this new library as described here: https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Request_for_Testing Testing Window: The mozilla::pkix certificate verification library is available for testing now in Nightly Firefox builds. We ask that you test as soon as possible, and that you complete your testing before Firefox 31 exits the Aurora branch in June. (See https://wiki.mozilla.org/RapidRelease/Calendar) Request for Code Review The more people who code review the new code, the better. So we ask all of you C++ programmers out there to review the code and let us know if you see any potential issues. https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Request_for_Code_Review We look forward to your help in testing and reviewing this new certificate verification library. Mozilla Security Engineering Team -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Announcing Mozilla::PKIX, a New Certificate Verification Library
On 04/26/2014 01:44 AM, Erwann Abalea wrote: Took a quick look at the code, it looks like KU/EKU checks is ok, BasicConstraints checks are weirdly done, NameConstraints checks are hard to follow, CertificatePolicies checks is a joke. I now notice that I didn't see date checks (I may have missed it). Init part of the validation code follows RFC5280 algorithm, but that's all. Revocation checking is done by OCSP only. And there's a LOT of magic values everywhere; I noticed them first for OID comparisons, but there's little to no use of an ASN.1/DER parser (IIRC, there's already 2 implementations in NSS). Erwann, It would be a great help if you could either expand on the issues you found here or file bugs in bugzilla. The sooner we catch and deal with issues the better. Date checks are done here: https://mxr.mozilla.org/mozilla-central/source/security/pkix/lib/pkixcheck.cpp#29 There's a minimal DER decoder here: https://mxr.mozilla.org/mozilla-central/source/security/pkix/lib/pkixder.h that implements what is needed for this library and nothing more (for example, https://mxr.mozilla.org/mozilla-central/source/security/pkix/lib/pkixocsp.cpp makes heavy use of it). Thank you, David -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Announcing Mozilla::PKIX, a New Certificate Verification Library
On Fri, Apr 25, 2014 at 6:59 AM, Erwann Abalea eaba...@gmail.com wrote: Le vendredi 25 avril 2014 13:46:51 UTC+2, Martin Paljak a écrit : On Thu, Apr 24, 2014 at 9:07 PM, Kathleen Wilson kwil...@mozilla.com wrote: Also, we added a section to the wiki page to list some behavior changes that could cause a website certificate to no longer validate with Firefox 31. https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Behavior_Changes What is the rationale for this: 4. Mozilla::pkix performs chaining based on issuer name alone, and does not require that issuer's subject key match the authority key info (AKI) extension in the certificate. Classic verification enforces the AKI restriction. AKI is only a helper for certificate path building. It's mandatory for CAs to issue certificates with matching keyIdentifiers (issued.AKI.keyIdentifier = issuer.SKI), but it's not mandatory for relying parties to verify that the values match. Erwann (and all), AKI is necessary for multiple public keys used by the same Subject certifier. It's particularly useful for a rolling chain of public keys, each one used to sign certificates within a given period of months, but with overlapping validity periods. 0 3 6 9121518212427 |u|v|v|v|v|.|.|.|.| |.|u|v|v|v|v|.|.|.| |.|.|u|v|v|v|v|.|.| |.|.|.|u|v|v|v|v|.| |.|.|.|.|u|v|v|v|v| In this diagram, 'u' means in use. 'v' means valid. The numbers at the top refer to 'counted months'. So, in this case, the private keys are used for 3 months while their issued certificates are valid for up to 12 months. There are 5 potential keys, identifiable only through the use of the AKID extension. Yes, the certified entity is supposed to provide its verifiable chain, back to the root (but not including the root)... at least, according to TLS, and other IETF Security working-area client protocols. But, it's not mandatory per PKIX, and it's also not mandatory per X.509, either. I believe this to be a poor design decision on the part of Mozilla. -Kyle H -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Announcing Mozilla::PKIX, a New Certificate Verification Library
On Mon, Apr 28, 2014 at 4:45 PM, Erwann Abalea eaba...@gmail.com wrote: The chain builder can test all possible issuers until it finds a valid one (that's what OpenSSL does, for example). The AKI is only here to say pssst, this is most probably the certificate you should try first. Right. We need to measure whether our lack of support for AKI/SKI, which causes us to do such a brute-force search, actually causes real-world performance concerns. I am hoping that it doesn't matter so that we can remove AKI/SKI from the WebPKI X.509 profile. There's another missing check on the new PKIX lib, PrivateKeyUsagePeriod extension. It's been declared as deprecated in RFC2459 and 3280, isn't mentioned anymore in RFC5280, but it's still defined in X.509, and used on some places, such as CSCA (e-passports, where CA renewal with rekey also happen on a regular basis). CSCA is out of scope for mozilla::pkix, at least at this time. More generally, PrivateKeyUsagePeriodand other deprecated features, including *all* of the proprietary Netscape/NSS extensions like Netscape Cert Type, are also out of scope. Note that new features like the Must-Staple extension *are* within scope and can/should/will be added. I agree, it's not mandatory at all. And even if a bunch of certificates is sent along the EE cert, the RP is supposed to take them as potential candidates for its chain building algorithm. Potential candidates only. Exactly. (In the code, the candidate issuer is called potentialIssuer.) Thanks for looking so closely at the code. Please let me know if you have any questions that would help with your investigation of it. Cheers, Brian -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Announcing Mozilla::PKIX, a New Certificate Verification Library
Le vendredi 25 avril 2014 21:09:58 UTC+2, Martin Paljak a écrit : On Fri, Apr 25, 2014 at 4:59 PM, Erwann Abalea eaba...@gmail.com wrote: AKI is only a helper for certificate path building. It's mandatory for CAs to issue certificates with matching keyIdentifiers (issued.AKI.keyIdentifier = issuer.SKI), but it's not mandatory for relying parties to verify that the values match. While I might agree to the reasoning behind why it doesn't matter, I don't see why a cautious implementation (not to call it *paranoid* which might have a different meaning to some) does not *check* what others are *required to do*. And do that *by default*. Not doing it under some more relaxed conditions (export cipher anyone ?). Priorities. Let them first do their mandatory duties, and *then* add some paranoid checks. Took a quick look at the code, it looks like KU/EKU checks is ok, BasicConstraints checks are weirdly done, NameConstraints checks are hard to follow, CertificatePolicies checks is a joke. I now notice that I didn't see date checks (I may have missed it). Init part of the validation code follows RFC5280 algorithm, but that's all. Revocation checking is done by OCSP only. And there's a LOT of magic values everywhere; I noticed them first for OID comparisons, but there's little to no use of an ASN.1/DER parser (IIRC, there's already 2 implementations in NSS). -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Announcing Mozilla::PKIX, a New Certificate Verification Library
On Thu, Apr 24, 2014 at 9:07 PM, Kathleen Wilson kwil...@mozilla.com wrote: Also, we added a section to the wiki page to list some behavior changes that could cause a website certificate to no longer validate with Firefox 31. https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Behavior_Changes What is the rationale for this: 4. Mozilla::pkix performs chaining based on issuer name alone, and does not require that issuer's subject key match the authority key info (AKI) extension in the certificate. Classic verification enforces the AKI restriction. ? -- Martin +372 515 6495 -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Announcing Mozilla::PKIX, a New Certificate Verification Library
Le vendredi 25 avril 2014 13:46:51 UTC+2, Martin Paljak a écrit : On Thu, Apr 24, 2014 at 9:07 PM, Kathleen Wilson kwil...@mozilla.com wrote: Also, we added a section to the wiki page to list some behavior changes that could cause a website certificate to no longer validate with Firefox 31. https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Behavior_Changes What is the rationale for this: 4. Mozilla::pkix performs chaining based on issuer name alone, and does not require that issuer's subject key match the authority key info (AKI) extension in the certificate. Classic verification enforces the AKI restriction. AKI is only a helper for certificate path building. It's mandatory for CAs to issue certificates with matching keyIdentifiers (issued.AKI.keyIdentifier = issuer.SKI), but it's not mandatory for relying parties to verify that the values match. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Announcing Mozilla::PKIX, a New Certificate Verification Library
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 04/25/2014 09:59 AM, Erwann Abalea wrote: Le vendredi 25 avril 2014 13:46:51 UTC+2, Martin Paljak a écrit : What is the rationale for this: 4. Mozilla::pkix performs chaining based on issuer name alone, and does not require that issuer's subject key match the authority key info (AKI) extension in the certificate. Classic verification enforces the AKI restriction. AKI is only a helper for certificate path building. It's mandatory for CAs to issue certificates with matching keyIdentifiers (issued.AKI.keyIdentifier = issuer.SKI), but it's not mandatory for relying parties to verify that the values match. That doesn't seem like enough of a justification to me. It may not be mandatory, but please explain why it is not *necessary* (i.e. why no security guarantees depend on it). zw -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBCAAGBQJTWorRAAoJEJH8wytnaapkkO8QAI4IrF43KkSBzkN6YcZ6gvUu 2xqzkZGSJJDHJkrJJCIEAlcpLPWlXfrhCuhhr5+tXQ6hgKm+i5HCCsE+vkd9bqHx FQO+Qg/pG+Y1UWfJ57/0FuUwffl42ox+6zXeQPSEVDmB3nXaVxpJuLgIQpU6Pvp2 E/pc8E6FHJ1Ua6SHqSNFYj8qirtu8wnKu2ubhnbYfNJKRqgLjufe6bAPjunnwj/5 TbABPSkgll9drHtc5KzNyG6zWlboVdyNLZEVOkzsmXAusy0fRYiqK5U05BexGPdZ m7lsfmj78hvSe1Un+C6h4scvi9MLs851HBiJopAV0rltvZBryZZxE0nmYswZp3bo GrHylX/Yxx5AddQl8A3BDR5HfI/xSFej0VgAhSChNmkSVLROAFpSlK0IuYfhtxd6 OkxfDhBDgCVY/tB89kXmu0vzW9xwjsgmFQ0vvHHVJwdOfJXs8Cky1LWextIdUc5y zEmiM5pfd/GRutTHKjK7dWNqj1mpK6uJbM8QIG0tMOcpJ41Ja8rXYhKem9LIBjf6 s2j19puGw0Vgi9mmSfqrRL4IiW677m3vizXHMgeFkyKwMkJHRNU7IVN+8N+KTQ7n flhjXTf/A8OJWpcQWIdiQrx73ul/jxGoROsQ+HkcfWhTQWa/ZHdPxd2ivyl3xGc0 yxo93+ET5uXRGoY24EVx =dTnD -END PGP SIGNATURE- -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Announcing Mozilla::PKIX, a New Certificate Verification Library
On 4/25/14, 9:18 AM, Zack Weinberg wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 04/25/2014 09:59 AM, Erwann Abalea wrote: Le vendredi 25 avril 2014 13:46:51 UTC+2, Martin Paljak a écrit : What is the rationale for this: 4. Mozilla::pkix performs chaining based on issuer name alone, and does not require that issuer's subject key match the authority key info (AKI) extension in the certificate. Classic verification enforces the AKI restriction. AKI is only a helper for certificate path building. It's mandatory for CAs to issue certificates with matching keyIdentifiers (issued.AKI.keyIdentifier = issuer.SKI), but it's not mandatory for relying parties to verify that the values match. That doesn't seem like enough of a justification to me. It may not be mandatory, but please explain why it is not *necessary* (i.e. why no security guarantees depend on it). Lets pretend for the sake of the argument that you are an attacker and can modify the value of the AKI (assume that the AKI is not signed by the CA). You will notice that this field is NOT used to determine your identity (like the name or subject-alt-names) you or the determine capabilites of your cert (and private key) (like the basic constraints, KU, EKU, Cert Policies, name constraints extensions). Is it more clear now? Camilo -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Announcing Mozilla::PKIX, a New Certificate Verification Library
On Fri, Apr 25, 2014 at 4:59 PM, Erwann Abalea eaba...@gmail.com wrote: AKI is only a helper for certificate path building. It's mandatory for CAs to issue certificates with matching keyIdentifiers (issued.AKI.keyIdentifier = issuer.SKI), but it's not mandatory for relying parties to verify that the values match. While I might agree to the reasoning behind why it doesn't matter, I don't see why a cautious implementation (not to call it *paranoid* which might have a different meaning to some) does not *check* what others are *required to do*. And do that *by default*. Not doing it under some more relaxed conditions (export cipher anyone ?). Best, -- Martin +372 515 6495 -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Announcing Mozilla::PKIX, a New Certificate Verification Library
On 4/7/14, 3:33 PM, Kathleen Wilson wrote: All, We have been working on a new certificate verification library for Gecko, and would greatly appreciate it if you will test this new library and review the new code. A special Bug Bounty program has been announced regarding this: https://blog.mozilla.org/security/2014/04/24/1-security-bug-bounty-for-certificate-verification/ Also, we added a section to the wiki page to list some behavior changes that could cause a website certificate to no longer validate with Firefox 31. https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Behavior_Changes Kathleen -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
