Re: Loading http:// from file://
On 2010-12-16 01:30 PDT, jfr wrote: Hi all, I'm developping an application based on xulrunner 1.9.2. I need to load a page, say http://xxx, from file://yyy. xulrruner raises an error as Security Error : content at http://xxx may not load data from file:///yyy. Which is backwards of what's really trying to be done, yes? Or is it? I'd say either a) a bug is causing references from file:// to http:// to be treated as if they were references from http:// to file://, OR b) the file-http reference is actually working OK, but then the http content tries to reference file:// content, which fails. -- /Nelson Bolyard ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Who is using NSS in their projects?
On 2010-03-03 10:58 PST, Shailendra Jain wrote: Is this source of information about Linux planning to integrate NSS as main security features available some where in the web or in Linux doc? RedHat is doing this for RedHat Linux. I'm sure you will find info on RedHat's web site. I don't know how much (if any) this will affect other distro's. NSS is part of the LSB (Linux Software Base or Linux System Base), which means that you can count on it being in all Linux distros, but the important question (to me) is whether the system programs themselves will rely on it for their crypto security. I believe the answer will be yes for RH Linux. I'm not as optimistic for the other distros. ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Who is using NSS in their projects?
On 2010-03-02 10:06 PST, davidwboswell davidwbosw...@yahoo.com wrote: I maintain a list of applications that use Mozilla technologies in their projects and wanted to add more examples of projects that use NSS. http://www.mozilla.org/projects/mozilla-based.html There are lots of applications that use NSS but use no other aspect of mozilla technologies. Perhaps you should have a separate list of these. For example, of the network server software products offered by Sun Microsystems that are not written in Java, most use NSS. AOL Instant Messenger used NSS for years, and recent versions still include the NSS libraries, but don't seem to actually use them. I had seen references to Apache using NSS in mod_nss so I included it as a featured application and then blogged about it. In the comments on that post though, there were questions if Apache was really using NSS or not. Apache has a plug-in architecture. There are many plug-ins for it. Some are co-developed by the Apache developers themselves and are distributed along with Apache. Others are developed independently and distributed independently (or distributed together with Apache in downstream distros). mod_nss is one of the latter. There are many others. I'd also like to promote other NSS users, so if there's a list somewhere like the XULRunner Hall of Fame or if anyone wants to just post here with some examples, that would be great. I'm cross posting this in mozilla.dev.tech.crypto, which is where most developers who use NSS hang out. Maybe some of them will volunteer info about their products that use NSS. ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: security.OCSP.require in Firefox
Daniel Veditz wrote: On 10/13/09 10:12 AM, Eddy Nigg wrote: #B is important because we are already month after the alleged bug happened, plenty of time to get the act together. I think this warrants some actions, a review and renewed confirmation of compliance might be a good thing to do in this case. These certs were revoked within days of the BlackHat talk. Only because you and I separately reported the problem to them. The leaked cert is an old cert, we are not talking about a CA clueless for the past ten weeks. IPSCA mailed us on Aug 3 that they had identified and revoked nine bogus certs and had stopped issuing any certs until they fixed their process to detect these attempts. Yes, that is what their emails to you and me said. I believe the part about them adding 9 certs to their CRL, and them stopping the issuance of certs until they made some changes to their software that examines CSRs. But adding certs to the CRL doesn't fully satisfy the CA's revocation duty. The certs they had issued contained OCSP extensions. Those extensions constitute a written promise to all relying parties that, if the cert is revoked, information about that revocation will be available at the given OCSP URI until the expiration date of the certificate. And that part of the promise was not, and is not now being, kept. From the domains involved we pretty much know who bought the certs, Moxie of course, and two other speakers we know about on the hacker-conference speaking circuit. What we didn't know is that any of those three were irresponsibly handing out the private keys to the certs. I submit that knowledge of who the attacker was and what his intentions were do not excuse a CA for failure to fulfill its duties to the relying parties. ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: cert_override.txt format
On 2009-08-10 15:32 PDT, Sid Stamm wrote: http://mxr.mozilla.org/mozilla-central/source/security/manager/ssl/src/nsCertOverrideService.cpp#259 This is a bit of NSS that reads the cert_override.txt file It's not NSS. If it was NSS, you would see /nss/ in the path name above. It's PSM, and the format of the file is a private interface, which means that it could change at any time in any release or any update. So, just be aware of that, and don't be upset if it changes. ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Shared security Db in FF-3.5?
On 2009-07-03 01:43 PDT, Andrei Korostelev wrote: Does Firefox 3.5 already support multi-process shared secrurity database or it is still single-process? By default, it is still the old single-process cert8 and key3 DBs, as before. However, FF 3.5 has the code to support shared-access cert9 and key4 DBs, based on sqlite3. You can force FF 3.5 to use that by setting an environment variable. Is non-shared security Db still the case with upcoming Firefox 3.5? The old non-shared security DBs are still the default in FF 3.5. Is SecurityDb in Firefox 3 multiuser? Multi-user is a different matter than multi-process. FF 3.5's new cert9 and key3 DB are multi-process capable, but I would NOT describe them as multi-user. They are a pair, and the private keys in the key DB are, of course, private to each individual user. So, each user needs his/her own key DB, and since they are a pair, this implies that each user needs his/her own cert DB too. But with cert9.db, all that user's processes can share a common pair of DBs. ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Return of i18n attacks with the help of wildcard certificates
Jean-Marc Desperrier wrote, On 2009-02-20 07:55: Eddy Nigg wrote: On 02/19/2009 03:30 PM, Jean-Marc Desperrier: Moxie Marlinspike in Black Hat has just demonstrated a very serious i18n attack using a *.ijjk.cn certificate. http://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf .cn is authorized for i18n, and the * will match anything, allowing all the classic i18n based attacks. This was striking: Get a domain-validated SSL wildcard cert for *.ijjk.cn Wildcards are not an essential part of this attack. They merely were a convenience for this demonstration, but the attack could have been done without using a wildcard cert. Even eliminating wildcard certs altogether would not stop this attack. This being said : Is there already a bug open for this ? The only thing that stops me opening it myself is that it might already exist but be security restricted. Yes, there is, and yes, it is. ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Bad Record Mac
Roy Donaldson wrote, On 2008-12-19 12:27 PST: I'm trying to create a FIPS 140-2 compliant SSL connection using the Sun JSSE (SunPKCS11) and NSS. I suppose you mean a FIPS compliant TLS connection. TLS is SSL version 3.1 (or newer). FIPS 140 compliance requires the use of TLS. Crypto questions are best asked in mozilla.dev.tech.crypto rather than in mozilla.dev.security. I have redirected followups to m.d.t.crypto. In my code, I'm able to create a keystore that can pull my certificate (for 127.0.0.1) from the NSS db and display it's information. However, when I try to connect a client socket and a server socket, I receive this exception: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:174) at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:136) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.recvAlert(SSLSocketImpl.java:1657) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:932) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1096) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1123) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1107) ... javax.net.ssl.SSLHandshakeException: bad handshake record MAC at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:174) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1591) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1549) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:847) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1096) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:744) at com.sun.net.ssl.internal.ssl.AppInputStream.read(AppInputStream.java:75) at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:264) at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:306) at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:158) at java.io.InputStreamReader.read(InputStreamReader.java:167) at java.io.BufferedReader.fill(BufferedReader.java:136) at java.io.BufferedReader.readLine(BufferedReader.java:299) at java.io.LineNumberReader.readLine(LineNumberReader.java:182) ... I'm not sure what Bad Record MAC means, or how to go about fixing it. It usually means that, at the end of the handshake, the client and the server ended up with different keys, and the attempt to decrypt an encrypted record received from the remote peer party produced a decrypted result that is unintelligible. I thought that perhaps it was a hint that my certificate was corrupt, No, there are different errors that occur when a cert is bad. It might mean that your server is using the wrong private key, not the one that corresponds to the public key in the cert. Does anyone have any suggestions on where to start looking? Is this a sign that I have NSS or certificates configured incorrectly, or should I be talking with the Sun gurus about my implementation? Your message may get help from others in the mozilla.dev.tech.crypto newsgroup (which is also the dev-tech-crypto AT lists.mozilla.org mailing list). Sun Java gurus who best know the internals of the class com.sun.net.ssl.internal.ssl.SSLSocketImpl may be able to provide more help. Are you sure that your client and server are actually using NSS's PKCS#11 module? The exception stacks shown above provide no evidence that proves or disproves that they do. Still, a common problem is that the software is not using the provider that the developer imagines it is using. ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: NSS Binaries
Roy Donaldson wrote, On 2008-12-11 11:00: I'm sure the answer is somewhere out there, but I can't seem to find it no matter where I look. Are there binary distributions of NSS (specifically, the slightly older versions that are FIPS 140-2 certified) for download, or do I need to compile from source for each platform that I'll be distributing to (Windows, Linux, Solaris..)? Any binary distributions that exist are found in ftp://ftp.mozilla.org/pub/mozilla.org/security/nss/releases/ If you don't find what you want in there, you'll have to build it yourself. ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: PR_Sleep question,help!
Note: cross posted to mozilla.dev.tech.nspr.
Follow up messages are directed there.
lixiangfeng wrote, On 2008-09-26 01:39:
Hi,I write a program use mozilla nss .
My process will scan some variable for a expected value.when the variable
equals some value,my process will dosomething.So,I call PR_Sleep(1second)
for some time interval.
When my program run in solaris,some shell-base program run on it,this
program will start work at 00:00:00,it will adjust the date of computer to
the last day,So,the date of computer will keep in one day.
I think you're saying that your shell program sets the system clock back
24 hours every day at midnight, causing the system to keep re-traversing
the hours of a single date. (This sounds like something that might have
been done to avoid Y2k problems. :)
Do I understand that correctly?
In this condition,My Program will hung at PR_Sleep,but why?
I think, PR_Sleep will calculate the wait time for sleep function, when time
just(to the last day or adjust to early),PR_Sleep whill block util to it's
schedule time?
Yes, that's basically right.
You'll find relevant code at these URLs:
http://mxr.mozilla.org/security/source/nsprpub/pr/src/pthreads/ptthread.c#783
http://mxr.mozilla.org/security/source/nsprpub/pr/src/md/unix/solaris.c#57
is it a bug of PR_Sleep?
The question is: how is PR_Sleep defined to behave when the clock is set
backwards? Is the present behavior consistent with that definition or not?
If not, then it is a bug.
Some definitions are given at
http://mxr.mozilla.org/security/source/nsprpub/pr/include/prthread.h#260
http://developer.mozilla.org/en/PR_Sleep
Those definitions do not answer the question: what if the system time
is set backwards?
I think the NSPR developers are likely to say that the definition should be:
The behavior is undefined if the system clock is set backwards.
or my function call problem? Can someone help
me?thanks!!!
int a = 0;//a will be change by other process or thread
//.
while(1){
PR_Sleep(10);
I think your program is assuming that the time interval for PR_Sleep
is tenths of a second, or seconds. But it may be neither. The way to
sleep for one second is:
PR_Sleep(PR_SecondsToInterval(1));
But that is not the cause of the problem you reported.
I suggest that you to go https://bugzilla.mozilla.org/ and register your
email address there, then file a bug against product NSPR about this.
That bug will then be the place where this issue will be decided, and
if the NSPR developers decide to change the code, that will be the place
where progress is recorded.
It might be reasonable for PR_Sleep to attempt to detect time going
backwards, and attempt to minimize the effect of that by estimating the
amount of time adjustment and modifying the starting time accordingly.
On the other hand, attempting to minimize the effect of time going
backwards could cause a problem in the following situation:
- a program tries to sleep for 12 hours
- 5 minutes later, an operator mistakenly sets the system time back 24
hours.
- NSPR detects this and tries to compensate by adjusting the starting
time backwards.
- 5 minutes later, an operator corrects the system time by setting it
forward 24 hours.
- NSPR is likely to terminate the sleep prematurely in that case.
NSPR could attempt to detect large time offsets in either direction, and
compensate for them, but this might have consequences on overhead and
performance, and might lead to oscillation.
I look forward to seeing your bug report.
___
dev-security mailing list
dev-security@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security
Re: TLS, if available in Thunderbird
Ben Bucksch wrote, On 2008-09-17 13:55: Thunderbird currently has the SSL options: Never (plain), TLS, if available, TLS (always), and SSL (always), for incoming IMAP/POP3 and outgoing SMTP servers (with slightly different UI wording). TLS is basically SSL version 3. Damn! Those old wrong labels are STILL in use? Even after bug 185662 was allegedly fixed? Please read all the way through bug 185662 and bug 350314. Those bugs will explain that the mode labeled as TLS is actually STARTTLS, which is something very different. I've been trying to get those labels replaced with something better for years. Bug 350314 also explains that the TLS if available option should be called StartTLS, unless there's an attacker. That option should just go away. It is trivially attacked. Even if the server really does offer TLS, an attacker can easily fool the client into thinking that the server does not, so the client will not use TLS even though it is available. The idea you proposed, of using TLS, if available as a way to just cause the one-time automatic detection and account configuration has been proposed in several bugs, including bug 350314 comment 12. It was rejected four months ago because of an alleged string freeze. The major news you've added in this email is that this exploit is now being massively utilized. That information should go into bug 350314. Sorry for my bad attitude. I've been calling attention to this issue for months, and getting at most a ho-hum response. Maybe now, the news that this is being massively exploited will finally get it some attention. ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Add own algorithm to NSS
bezuglyi wrote, On 2008-09-03 02:32 PDT: I want to add my own cipher algorithm to NSS library, like gost engine in openssl, is it possible? If yes can anyone explain the procedure You'll find more people who can help with this in the dev-tech-crypto mailing list, which is also the mozilla.dev.tech.crypto newsgroup. /Nelson ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Including all root certs in FF3
Rick Andrews wrote on 2008-03-04 16:36 PST: Where can I find a list of features included in FF3? Does it include support for SHA-256 and ECC? The cryptographic algorithms and TLS cipher suites supported in FF3 will be the same as in present versions of FF2, with the following additional cipher suites: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA, TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA, TLS_RSA_WITH_CAMELLIA_256_CBC_SHA, TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA, TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA, TLS_RSA_WITH_CAMELLIA_128_CBC_SHA, which use the Japanese Camellia cipher. /Nelson ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: error code 12205
Boris Zbarsky wrote, On 2008-02-26 21:32 PST: Vladi Rocha wrote: Hi developers. I am trying to avoid the popup when you remove a token PKCS11 while an operation was in progress. You probably want mozilla.dev.tech.crypto for this question... Unfortunately, this is a PSM question, not an NSS question, because it deals with UI issues, and (as you know) NSS doesn't do UI. AFAIK, there's only one PSM developer in the whole universe, and he doesn't apparently have time to hang out in newsgroups. ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Extract of CA certificates
Gervase Markham wrote, On 2008-02-09 02:35: Eddy Nigg (StartCom Ltd.) wrote: Since sometimes there are some licensing concerns with the certdata.txt file, I wanted to know exactly what one is allowed to do. If for example by merely extracting the CA certificates with a tool like http://curl.haxx.se/lxr/source/lib/mk-ca-bundle.pl still requires the resulting CA bundle to be bound to the tri-license of Mozilla? Or can I simply extract all CA certificates from the browser by exporting them? I think the correct position is that the certdata.txt file is data used by Mozilla, rather than part of the browser itself. That file is used during the process of compiling and building the browser. Its contents are transformed into c code that becomes part of a file that is compiled into the browser. That file is certdata.c in the same directory as certdata.txt. The copyright in the certificates technically rests with the CAs, but it would be a very strange CA which forbade you from shipping their certificate in your product. I'm not sure what the legal position would be there. As I recall, at one time, at least one of the CAs whose root CA certificates are now found in certdata.txt had a policy that their root CA certificates were to be published ONLY as part of products to which they had explicitly given permission to distribute them. That CA did not make its root CA certificates available for direct download from any of its web sites or FTP servers, and it forbade others to distribute its root CA certificates in that way, on pain of prosecution for copyright infringement. When NSS was finally able to be open-sourced late in the year 2000, that CA was required to agree to allow its certificates to be distributed in various other fashions, in accordance with the MPL, in order for those certs to be eligible to become part of the NSS open source. I suppose there are records of that agreement somewhere, but I don't know where, or even who were the parties that executed the agreement. But nonetheless, I believe that the appearance of any CA's root certs in NSS's root cert list is evidence that, at one time in the past, the NSS developers believed they had explicit permission from that CA to include its certs in a file distributed under MPL terms. And so I believe the MPL terms still fully apply today. /Nelson ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Accepting certificates
Stefanos, If you'[re really worried about students being MITM attacked, then you might ask why the University has so many https sites using invalid certs which necessitate the users getting this dialog in the first place. Don't worry, in FF3, this dialog will go away completely. ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: EV Draft Review Discussion
Gervase Markham wrote: Eddy Nigg (StartCom Ltd.) wrote: The fact that connections to expired certificates are allowed by most if not all browser vendors contributes to this problem, if this certificate is removed from the CRL...than it's just an expired certificate which was once valid, compared to a certificate which is actually revoked. Indeed. For Firefox 3, we plan to treat revoked and expired equally, preventing access in both cases. Gerv, I am SO delighted to hear that! But, I have not heard (or read) it anywhere else. :-/ I gather that a lot of decisions about being made about the handling of security errors and overrides for FF3, decisions that may change the way things work significantly. I applaud that, especially if it results in fewer security errors being overridable on the spur of the moment by someone who is actively falling for a phishing attack.. But where are these decisions being recorded? Where can I go to read about them, and try to keep up with them? /Nelson ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: VeriSign Class 3 Secure Server CA?
Eddy Nigg (StartCom Ltd.) wrote: Nelson Bolyard wrote: Yes, there is a standard for certs that allows (but does not require) relying parties to go search on the internet for missing intermediate CA certs. Do you have the quote from the corresponding RFC for this? It's RFC 3280 section 4.2.2.1, Authority Information Access Too big to quote here. But that standard does NOT relieve SSL servers of the obligation to send their entire server cert chains Correct. Later, Eddy wrote: If there is such a standard which suggests it as an option, than I think Mozilla should implement it We're working on it. Now up to 60,000 lines of new code for it, and still growing. This feature is actually necessary in bridge CA (a.k.a. Cross certified CA infrastructures, which are now beginning to emerge, mostly in Asia. Earlier, Eddy wrote: At our CA, we have a robot checking for missing ICA certificatesand send an appropriate message to the subscriber... And by the subscriber, Eddy means the web site administrator who acquired the cert for his server. Eddy, that's brilliant. It's a service that adds tremendous value for your subscribers and all their users/customers. I wish more CAs did that. ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: VeriSign Class 3 Secure Server CA?
Throughout the lifetime of mozilla browsers, there have been innumerable web sites that worked with IE but not mozilla, because those web sites' content depended on IE behavior, and were not testing with any browser other than IE. Countless users have whined to mozilla with messages saying (in effect) your browser sucks because it isn't just like IE. Mozilla's answer has generally been this: Mozilla products work with all web sites that conform to the relevant standards. This thread is no different in any respect. There are some people for whom the best answer is use IE. Those are people who insist that any product that doesn't render their favorite web site as well as IE is therefore inferior to IE. Those people will never be satisfied with anything but IE, and they should stop whining and use IE. People who say they really prefer mozilla browsers, but can't or won't use them because things are rendered differently than IE, are merely advocates for IE, trying to disguise their advocacy. To such writers, I say, If you want IE's behavior rather than standards-based behavior, you can get it all you want, by using IE. Please do. You won't make any friends here by continuing to belittle mozilla browsers for not being IE. ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: VeriSign Class 3 Secure Server CA?
Melelina wrote: The cert is issued to www.microsoft.ipsos.com by Verisign. Or it appears to be. I want to use Fx at Microsoft sites and I am very tired of Fx problems with Microsoft certs But you haven't yet shown any evidence of FF having a problem with a Microsoft site. The site you cited is NOT a Microsoft site. The cert for that server claims to have been issued to: O = IPSOS-REID Corporation L = Winnipeg ST = Manitoba C = US (Heh, I guess the US must have annexed Manitoba when I wasn't looking. :) If you DO have troubles with real Microsoft web sites, you can let me know. I have contacts among Microsoft web site admins, and when I report a problem with their servers, they often (not always) get fixed. They always reply, somewhat red faced, that they only tested with IE. I have no contacts in Manitoba. and now there is the problem of Fx not having the new Verisign intermediate cert Verisign's class 3 intermediate CA cert is not new. It was issued on April 16, 1997, 10 years ago (next month). It has been continuously in use by thousands of web sites all that time, with NO difficulty by mozilla browsers. Recently, Verisign discontinued issuing certs from their older RSA security root. Their customers (web site administrators) had been using server certs issued from the old RSA Security root for years, and had never in their lives ever installed an intermediate CA cert into their servers. Then, when they applied for renewed certs, they got certs issued by Verisign's class 3 intermediate CA. Verisign's web site explained to its subscribers the need to install the Intermediate CA cert into their servers. http://www.verisign.com/support/advisories/page_029264.html http://www.verisign.com/support/advisories/page_040601.html http://www.verisign.com/support/advisories/page_040611.html even in other languages (such as Japanese, here translated into English): http://babelfish.altavista.com/babelfish/trurl_pagecontent?lp=ja_enurl=http%3A%2F%2Fwww.verisign.co.jp%2Fserver%2Fabout%2F2006rollover%2Fssid%2Findex.html But many Verisign customers took no notice of those instructions. So, those web sites, operated by people who didn't read the notices, now have problems. The fault isn't FireFox's, nor Verisign's. and it wanting to rely on root certs that are no longer used by Verisign. Wrong, on several counts. 1. Verisign's old RSA Security Secure Server authority cert doesn't expire until 2010. Until then, server certs issued by that CA will continue to validate against that root CA cert. 2. ALL certs are verified by following a chain (or path) of CA certs, beginning with the issuer of the server cert, then the issuer of that cert, and so on, until we come to a root CA cert (which is its own issuer). If the chain is incomplete, so that we cannot follow it all the way to the root, then the server cert cannot be verified. Servers that send out incomplete cert chains are violating the standards for SSL 3.0 and/or TLS (SSL 3.1), which require servers to send out their entire cert chains, up to (but not including) the root CA. An SSL server that doesn't send its intermediate CA certs is simply non-conformant and mis-configured. RFC 2246, the standard definition of TLS (SSL 3.1) says: certificate_list This is a sequence (chain) of X.509v3 certificates. The sender's certificate must come first in the list. Each following certificate must directly certify the one preceding it. Because certificate validation requires that root keys be distributed independently, the self-signed certificate which specifies the root certificate authority may optionally be omitted from the chain, under the assumption that the remote end must already possess it in order to validate it in any case. Yes, there is a standard for certs that allows (but does not require) relying parties to go search on the internet for missing intermediate CA certs. But that standard does NOT relieve SSL servers of the obligation to send their entire server cert chains (minus the root CA cert, which is optional). At least this is what I understand the situation to be from threads at Mozillazine and dslreports security forum, etc. If this is not the case please enlighten me. Ah yes, those fonts of indisputable truth. :) The problems need to be fixed where they exist, in the misconfigured servers. Of course, it's easier to complain to mozilla, where in many cases you're more likely to get a reply, but the problem will be fixed when a sysadmin in Winnipeg fixes his server configuration. Maybe you can help him/her hasten that day. /Nelson B (mozilla SSL developer, IETF TLS member, co-author RFC 4492) ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Registerfly
Gervase Markham wrote: Nelson Bolyard wrote: Is FlySSL acting as a Registration Authority (RA) for Geotrust/Comodo? I don't think so; but how would I tell? Is the only way to tell by asking Geotrust and Comodo? That probably the best way. Or is there something that has to be in the issued certs? Gerv ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Proposal for Mozilla CA policy extension
Eddy Nigg (StartCom Ltd.) wrote: Johnathan Nightingale [EMAIL PROTECTED] wrote: Imagine that we found a way to clearly present to the user: + Your connection is encrypted + The site's identity has been verified + You've been here many times before + This site is trusted by (your friends | bbbonline | other vendor rating sites) + This site appears on no blacklists [snip] I think, that the SSL stuff and the other indicators should be separated in some way, specially since the later apply to plain http as well (and are perhaps much more important in that respect, because of the missing indications of identity verification). Without SSL authentication of the site, the browser cannot honestly say any of the last 3 things in Jonathan's list. Without authenticating the site, you only know those properties of the URL, not of the site's content. The URL might be the same, but the actual site might be different due to any number of attacks (e.g. DNS cache poisoning, malicious router tables, hosts file poisoning). It is IMPOSSIBLE to tell, by examining site content only, whether you are at the site you think you are, or not. (If there is one point on which we should educate users, that's it!) Without authentication, the best you can say about those last 3 items are: + You've used this URL (or domain name) many times before + This URL (or domain name) is recommended by (friends, other sites) + This URL (or domain name) appears on no blacklists Identity is a piece of online safety, but it isn't all of it, Agreed, but reputation information is useless without authentication. Otherwise, a user will be relying on the reputation of a valid site while visiting an attacker's site. That's the very essence of phishing, and you cannot eliminate it without authentication. ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
