Resolving concerns about the IPS SERVIDORES root certificate
Kathleen Wilson
certificate owned by IPS:
OU = Certificaciones
O = IPS Seguridad CA
CN = IPS SERVIDORES
Valid From: 1998 Jan 01
Valid To: 2009 Dec 29
Key length: 1024
Signature Algorithm: MD5
The problems of note are:
1) Issuance of embedded-null certificates
2) OCSP responder not working
3) Issuing certificates with validity after the root expires
As a result, Mozilla has requested that IPS take the following
actions:
1) Provide an OCSP server which is alive and responding properly to
requests again.
2) Provide information about the steps IPS has taken to ensure that
revocation information continues to be available.
3) Provide information about the steps IPS has taken to ensure that no
new embedded-null certificates are issued.
4) Provide an explanation of why IPS is issuing certs from this root
that have a longer lifespan than the root.
5) Provide a timeline for a new audit against these revised practices.
Due to the serious nature of recent events, Mozilla has requested that
the action items be completed by the end of October 2009. If the
action items are not completed within this timeframe, Mozilla plans to
turn off the trust bits for this root (essentially disabling it). If
the action items are completed within this timeframe to a level which
alleviates the current concerns, then the trust bits for this root
will not be changed.
The action items are being tracked in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=523652
Kathleen
Eddy Nigg
> 4) Provide an explanation of why IPS is issuing certs from this root
> that have a longer lifespan than the root.
>
That item is really a curiosity. Essentially this root disables itself
anyway in two month. The better question is, what happens to their other
roots and if one of the other roots actually continues the legacy of
this root (same DN for example).
At this stage I suggest to also have a closer look on their other
roots. For example I just picked on of those builtin roots and
surprisingly found an OCSP URI in the AIA extension of the root:
http://ocsp.ips.es/
Not only that, all the other roots have the very same OCSP URL. As I
indicated previously, I HIGHLY suspect that this doesn't work. Do you
intend to require item #1 to be applied to all roots and all
certificates they issued? We'd need probably some certs to test, but I
guess Robin & Rob will be able to help out with that (they have all
kinds of robots crawling for certificates).
> Due to the serious nature of recent events, Mozilla has requested that
> the action items be completed by the end of October 2009.
Not sure what you want to disable, a root which expires in two month
anyway? Doesn't make much sense I'd say, nor is this really making any
impression on anybody. But we are not here to make some good
impression, rather to protect the users. I think there are some
indications that Mozilla should look at the overall handling under these
circumstances, singling out one root isn't reasonable.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
David E. Ross
Is there any connection between IPS Seguridad CA and IPS Internet
Publishing Services, both of which are based in Barcelona, Spain? The
latter also has certificates in the NSS database.
--
David E. Ross
<http://www.rossde.com/>
Go to Mozdev at <http://www.mozdev.org/> for quick access to
extensions for Firefox, Thunderbird, SeaMonkey, and other
Mozilla-related applications. You can access Mozdev much
more quickly than you can Mozilla Add-Ons.
Kathleen Wilson
> Publishing Services, both of which are based in Barcelona, Spain? The
> latter also has certificates in the NSS database.
Yes. IPS has 7 roots currently in Mozilla. They were approved in bug
#232695, and included in NSS in bug #244982.
They are:
OU = Certificaciones
O = IPS Seguridad CA
CN = IPS SERVIDORES
1998 Jan 01
2009 Dec 29
1024
MD5
OU = IPS CA Timestamping Certification Authority
O = i...@mail.ips.es C.I.F. B-60929452
O = IPS Internet publishing Services s.l.
CN = IPS CA Timestamping Certification Authority
2001 Dec 28
2025 Dec 26
1024
SHA-1
OU = IPS CA Chained CAs Certification Authority
O = i...@mail.ips.es C.I.F. B-60929452
O = IPS Internet publishing Services s.l.
CN = IPS CA Chained CAs Certification Authority
2001 Dec 28
2025 Dec 26
1024
SHA-1
OU = IPS CA CLASE1 Certification Authority
O = i...@mail.ips.es C.I.F. B-60929452
O = IPS Internet publishing Services s.l.
CN = IPS CA CLASE1 Certification Authority
2001 Dec 28
2025 Dec 26
1024
SHA-1
OU = IPS CA CLASE3 Certification Authority
O = i...@mail.ips.es C.I.F. B-60929452
O = IPS Internet publishing Services s.l.
CN = IPS CA CLASE3 Certification Authority
2001 Dec 28
2025 Dec 26
1024
SHA-1
OU = IPS CA CLASEA1 Certification Authority
O = i...@mail.ips.es C.I.F. B-60929452
O = IPS Internet publishing Services s.l.
CN = IPS CA CLASEA1 Certification Authority
2001 Dec 28
2025 Dec 26
1024
SHA-1
OU = IPS CA CLASEA3 Certification Authority
O = i...@mail.ips.es C.I.F. B-60929452
O = IPS Internet publishing Services s.l.
CN = IPS CA CLASEA3 Certification Authority
2001 Dec 28
2025 Dec 26
1024
SHA-1
Note: IPS is aware of the NIST recommendation that 1024-bit roots be
phased out by the end of 2010. As such, they have new roots, which
they will be creating a root-inclusion request for.
Kathleen
PS: Eddy, I am aware of your questions, but I need to do some double-
checking before responding.
David E. Ross
While the third problem you cited (issuing subscriber certificates that
expire after the root expires) does not apply to the six roots under IPS
Internet Publishing Services (all of which don't expire until the year
2025), the fact that the CA is the same as for IPS Seguridad brings all
seven roots into question. Do we know that the other two problems do
not affect IPS Internet Publishing Services?
Eddy Nigg
Is there any connection between IPS Seguridad CA and IPS Internet Publishing Services, both of which are based in Barcelona, Spain? The latter also has certificates in the NSS database.Yes. IPS has 7 roots currently in Mozilla. They were approved in bug #232695, and included in NSS in bug #244982.
I really liked:
These null characters are not interpreted by browsers and this is because hackers have discovered a way to fool browsers when accessing https secure sites.
Without mentioning that it's much more that the hackers found a way to fool a CA than the browsers, but never mind that.
The comment is partly confusing, I still don't understand how they issued certificates beyond the life-time of the root, how the other certificates are related and why for **** sake there is still no working OCSP responder. Neither can I see how they intend to fix the responder to work for all the other certificate using the same AIA record.
In short, I think we need a translation of the translation in order to figure what they really meant to say there.
Incidentally it also shows very clearly that the inclusions of CAs performed at that time where extremely insufficient and completly lacking. I suspect that today this CA would have not been approved in its current form and practices without various improvements. In my opinion a rigorous review of that CA is required.
Varga Viktor
Were the other CAs checked against this?
Üdvözlettel/Regards,
Varga Viktor
Üzemeltetési és Vevőszolgálati Vezető
IT Service and Customers Service Executive
Netlock Kft.
> -----Original Message-----
> From: dev-security-policy-bounces+varga_v=netlo...@lists.mozilla.org
> [mailto:dev-security-policy-
> bounces+varga_v=netlo...@lists.mozilla.org] On Behalf Of Rob
> Stradling
> Sent: Monday, November 02, 2009 4:15 PM
> To: dev-secur...@lists.mozilla.org
> Cc: Kathleen Wilson
> Subject: Re: Resolving concerns about the IPS SERVIDORES root
> certificate
>
> Kathleen,
>
> I note that the "end of October 2009" deadline that you set ipsCA has
> now
> passed, and that ipsCA have made an effort to restore their OCSP
> Responder to
> working order. However, it is certainly *not* the case that their OCSP
> Responder is now "responding properly to requests again".
>
> http://ocsp.ipsca.com returns "unknown" (rather than "revoked") for
> Moxie
> Marlinspike's fake www.paypal.com certificate (for which the private
> key was
> published at http://seclists.org/fulldisclosure/2009/Oct/87).
>
> It also returns "unknown" (rather than "revoked") for Jacob Applebaum's
> "* on
> the internet (when exploiting libnss software)" certificate (for which
> the
> private key was published at
> https://www.noisebridge.net/pipermail/noisebridge-discuss/2009-
> September/008400.html).
>
> (Both of these certificates are marked as revoked on the CRL:
> http://www.ipsca.com/ipsca2002/ipsca2002CLASEA1.crl)
>
> What this means is that Firefox versions that don't use a version of
> NSS that
> has been patched for the embedded NUL vulnerability are still just as
> vulnerable as they were whilst ipsCA's OCSP Responder was completely
> off-line.
>
> You said:
> "Due to the serious nature of recent events, Mozilla has requested that
> the
> action items be completed by the end of October 2009. If the action
> items are
> not completed within this timeframe, Mozilla plans to turn off the
> trust bits
> for this root (essentially disabling it)."
>
> Your move.
>
> P.S. Yes, I work for a competitor CA so I am probably biased. But
> ipsCA
> really do need to do better than this!
> > _______________________________________________
> > dev-security-policy mailing list
> > dev-secur...@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-security-policy
> >
>
> Rob Stradling
> Senior Research & Development Scientist
> C.O.M.O.D.O - Creating Trust Online
> Office Tel: +44.(0)1274.730505
> Office Fax: +44.(0)1274.730909
> www.comodo.com
>
> Comodo CA Limited, Registered in England No. 04058690
> Registered Office:
> 3rd Floor, 26 Office Village, Exchange Quay,
> Trafford Road, Salford, Manchester M5 3EQ
>
> This e-mail and any files transmitted with it are confidential and
> intended
> solely for the use of the individual or entity to whom they are
> addressed.
> If you have received this email in error please notify the sender by
> replying
> to the e-mail containing this attachment. Replies to this email may be
> monitored by Comodo for operational or business reasons. Whilst every
> endeavour is taken to ensure that e-mails are free from viruses, no
> liability
> can be accepted and the recipient is requested to use their own virus
> checking
> software.
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
> _______________________________________________________________________
> Ezt az e-mailt virus- es SPAM-szuresnek vetettuk ala a filter:mail
> MessageLabs rendszerrel. Tovabbi informacio: http://www.filtermax.hu
>
> This email has been scanned for viruses and SPAM by the filter:mail
> MessageLabs System. More information: http://www.filtermax.hu
> _______________________________________________________________________
> _
_______________________________________________________________________
Ezt az e-mailt virus- es SPAM-szuresnek vetettuk ala a filter:mail MessageLabs rendszerrel. Tovabbi informacio: http://www.filtermax.hu
This email has been scanned for viruses and SPAM by the filter:mail MessageLabs System. More information: http://www.filtermax.hu ________________________________________________________________________________________
Kathleen Wilson
https://bugzilla.mozilla.org/show_bug.cgi?id=523652
"#1 - We are working in providing an OCSP service. We estimate that it could be working at the end of next week. Anyway, we will keep you updated."
I didn't realize that there was an issue with their request for one more week to resolve their OCSP issues. IPS posted the update before the deadline and posted the other information that was requested in the bug.
I apologize if my assessment was incorrect in it being OK for them to take the additional time to resolve their OCSP issues. Until the email today, no one mentioned their concerns to me about this extension.
However, at this point,since no one (including me) posted an objection in the bug about their need for more time to resolve the OCSP issues, I think it would be unfair to take away the time that they thought they had.
Kathleen
Üdvözlettel/Regards,
> "Due to the serious nature of recent events, Mozilla has requested that
> the
> action items be completed by the end of October 2009. If the action
> items are
> not completed within this timeframe, Mozilla plans to turn off the
> trust bits
> for this root (essentially disabling it)."
>
> Your move.
>
> P.S. Yes, I work for a competitor CA so I am probably biased. But
> ipsCA
> really do need to do better than this!
>
> On Wednesday 21 October 2009 19:41:53 Kathleen Wilson wrote:
Kathleen Wilson
https://bugzilla.mozilla.org/show_bug.cgi?id=523652
To summarize:
1) All 7 of the IPS roots use the same OCSP service. Only the IPS
SERVIDORES root has SSL certs in it hierarchy.
2) For the certificates currently chaining up to the IPS SERVIDORES
root whose validity goes beyond that of the root, IPS plans to re-
issue all of those certs under a new root.
Please post questions and follow-up in the bug.
Thanks,
Kathleen
Kyle Hamilton
I don't work for a competing CA. I'm simply talking from my stance as
a user. But, I agree: Yank the trust bits.
-Kyle H
On Mon, Nov 2, 2009 at 7:14 AM, Rob Stradling <rob.st...@comodo.com> wrote:
> Kathleen,
>
> I note that the "end of October 2009" deadline that you set ipsCA has now
> passed, and that ipsCA have made an effort to restore their OCSP Responder to
> working order. However, it is certainly *not* the case that their OCSP
> Responder is now "responding properly to requests again".
>
> http://ocsp.ipsca.com returns "unknown" (rather than "revoked") for Moxie
> Marlinspike's fake www.paypal.com certificate (for which the private key was
> published at http://seclists.org/fulldisclosure/2009/Oct/87).
>
> It also returns "unknown" (rather than "revoked") for Jacob Applebaum's "* on
> the internet (when exploiting libnss software)" certificate (for which the
> private key was published at
> https://www.noisebridge.net/pipermail/noisebridge-discuss/2009-
> September/008400.html).
>
> (Both of these certificates are marked as revoked on the CRL:
> http://www.ipsca.com/ipsca2002/ipsca2002CLASEA1.crl)
>
> What this means is that Firefox versions that don't use a version of NSS that
> has been patched for the embedded NUL vulnerability are still just as
> vulnerable as they were whilst ipsCA's OCSP Responder was completely off-line.
>
> You said:
> "Due to the serious nature of recent events, Mozilla has requested that the
> action items be completed by the end of October 2009. If the action items are
> not completed within this timeframe, Mozilla plans to turn off the trust bits
> for this root (essentially disabling it)."
>
> Your move.
>
> P.S. Yes, I work for a competitor CA so I am probably biased. But ipsCA
> really do need to do better than this!
>
> On Wednesday 21 October 2009 19:41:53 Kathleen Wilson wrote:
>> _______________________________________________
>> dev-security-policy mailing list
>> dev-secur...@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-security-policy
>>
>
> Rob Stradling
> Senior Research & Development Scientist
> C·O·M·O·D·O - Creating Trust Online
Eddy Nigg
> IPS provided an update in the bug on 10/28:
> "#1 - We are working in providing an OCSP service. We estimate that it could be working at the end of next week. Anyway, we will keep you updated."
>
> I didn't realize that there was an issue with their request for one more week to resolve their OCSP issues. IPS posted the update before the deadline and posted the other information that was requested in the bug.
>
> I apologize if my assessment was incorrect in it being OK for them to take the additional time to resolve their OCSP issues. Until the email today, no one mentioned their concerns to me about this extension.
>
> However, at this point,since no one (including me) posted an objection in the bug about their need for more time to resolve the OCSP issues, I think it would be unfair to take away the time that they thought they had.
>
>
Somehow these messages are coming in delayed anyway (at least for me).
However I haven't felt the need to object or otherwise complain or make
aware of the facts, since YOU've set the deadline already. Besides that,
which weekend did they mean? One which is still in 2009 or already in 2010?
Lets make something crystal clear! We are not baby-sitting CAs nor
interested in yanking any roots, however I think their attitude and
performance has been below any reasonable MINIMAL expectations. I mean,
how long can this take to bring an OCSP responder up and running? One
day? Two days? A week? But heck, this has been going on for months....
In my humble opinion the right thing to do at this point is to consider
all their roots included in Mozilla. The one which is mostly affected
will expire anyway, removing the trust bits might be appropriate, not
sure if it will make any difference until the next update of Firefox
though.
Eddy Nigg
> Rob:
>
> I don't work for a competing CA. I'm simply talking from my stance as
> a user. But, I agree: Yank the trust bits.
>
> -Kyle H
>
> On Mon, Nov 2, 2009 at 7:14 AM, Rob Stradling<rob.st...@comodo.com> wrote:
>
Why don't I see the message from Rob? Am I the only one?
Ian G
> However, at this point,since no one (including me) posted an objection in the bug about their need for more time to resolve the OCSP issues, I think it would be unfair to take away the time that they thought they had.
Well, it is nice to fix issues. But there seem to be some wider aspect
here.
Firstly, although we have discussed many times the need to resolve these
issues, there is no real set of rules or guidelines or process by which
this is done. We might see the IPS issue as a bit of an early case, or
maybe we should see the C..... and S..... issues over xmas as earlier
cases. Dunno, it's all experiences, it's good to share!
Secondly, I haven't seen any analyses of what exactly is the risk of
losses here. Just noticing a bug ... or the existance of a cert with a
null stuffed in it ... isn't really a proof of impending losses. E.g.,
the moxy (?) cert was pointless, could only be used for 1 domain as far
as I could see.
Of course some will shout bloody murder, but those who shout loudest are
also the most interested. So we need to separate interests with
scientific method. What is the analysis of risk and losses here?
Thirdly, as a matter of fact (of my observation at last), Mozilla has
taken charge of this issue and has more or less decided what to do. Or
at least, this is the way I saw it evolve. Forgive me if I missed
something here, but it does seem that there was not so much public
consultation on a remedy here.
Therefore (if my observation is correct) I suggest Mozilla stick with
it; make the decision(s) as to when and how, and simply let us know.
Meanwhile, we think about change for the future, not for this case.
Let's not shift the goalposts.
My thoughts only ... with no doubt to be corrected right and wrong.
iang
Eddy Nigg
> On 02/11/2009 19:39, Kathleen Wilson wrote:
>
>> However, at this point,since no one (including me) posted an
>> objection in the bug about their need for more time to resolve the
>> OCSP issues, I think it would be unfair to take away the time that
>> they thought they had.
>
>
> Well, it is nice to fix issues. But there seem to be some wider
> aspect here.
>
> Firstly, although we have discussed many times the need to resolve
> these issues, there is no real set of rules or guidelines or process
> by which this is done. We might see the IPS issue as a bit of an
> early case, or maybe we should see the C..... and S..... issues over
> xmas as earlier cases. Dunno, it's all experiences, it's good to share!
You just mentioned C... and S.....would you mind to look at the minor
difference of action and reaction? Regarding S..... I can proudly look
into the room and ask with a clear voice if there is any CA which was
protected better despite having had a bug in the software and which
reacted more efficiently in that situation? Where the promises for
revocation services broken by either C.... or S....? Or perhaps you want
to talk about another issue of last year's summer by another C....which
took about a month to fix their code? ;-)
>
> Secondly, I haven't seen any analyses of what exactly is the risk of
> losses here.
You can drive somebody nuts, that's for sure...I'm certainly at risk
loosing my temper...that should be considered a measurable loss.
> Just noticing a bug ... or the existance of a cert with a null
> stuffed in it ... isn't really a proof of impending losses. E.g., the
> moxy (?) cert was pointless, could only be used for 1 domain as far as
> I could see.
Oh nothing happened, just one of the most popular financial web sites is
potentially compromised by anybody using a wifi connection....well yes,
it's just one domain...now we can all lay back and relax.
> What is the analysis of risk and losses here?
I guess you can't measure it since you don't know, but I let you analyze
it scientifically as long as you want...for the others, we want SSL to
work for us reasonably.
>
> Thirdly, as a matter of fact (of my observation at last), Mozilla has
> taken charge of this issue and has more or less decided what to do.
Something like this.
> Or at least, this is the way I saw it evolve. Forgive me if I missed
> something here, but it does seem that there was not so much public
> consultation on a remedy here.
Perhaps because all sides agreed with the approach taken?
> My thoughts only ... with no doubt to be corrected right and wrong.
>
At least you are open for change...not all is lost perhaps ;-)
Rob Stradling
> IPS provided an update in the bug on 10/28:
> "#1 - We are working in providing an OCSP service. We estimate that it
> could be working at the end of next week. Anyway, we will keep you
> updated."
Hi Kathleen. Sorry, I'd forgotten about Bug 523652 so I hadn't spotted this
request from IPS for an extension on the "end of October 2009" deadline you
had set them. I have to agree with Eddy that IPS's response has been "below
any reasonable MINIMAL expectations", but I guess it's your/Mozilla's
prerogative to extend the deadline as you see fit.
IMHO, IPS should switch off their OCSP Responder again, until such time as
they can make it provide accurate certificate status information.
I'll have to go a bit off-topic (for this list) to back up that statement...
There are other side effects of their OCSP Responder returning "unknown"
instead of "revoked" for Moxie's fake www.paypal.com certificate. Certain
platforms (e.g. Internet Explorer and other Microsoft CryptoAPI-based
applications on Windows Vista/7) prefer OCSP to CRL. Until a few days ago,
these platforms would have noticed that IPS's OCSP Responder was unavailable
and then checked IPS's CRL and found Moxie's certificate to be revoked.
Today, these platforms will check IPS's OCSP Responder and find Moxie's
certificate to be unrevoked (and they won't check IPS's CRL)! I expect that
many affected users are still not patched against the Microsoft CryptoAPI
embedded NUL vulnerability, which means that IPS have so far only succeeded in
reactivating the potential for MITM attacks against IE users who are PayPal
customers. :-(
> I didn't realize that there was an issue with their request for one more
> week to resolve their OCSP issues. IPS posted the update before the
> deadline and posted the other information that was requested in the bug.
>
> I apologize if my assessment was incorrect in it being OK for them to take
> the additional time to resolve their OCSP issues. Until the email today,
> no one mentioned their concerns to me about this extension.
>
> However, at this point,since no one (including me) posted an objection in
> the bug about their need for more time to resolve the OCSP issues, I think
> it would be unfair to take away the time that they thought they had.
>
> > "Due to the serious nature of recent events, Mozilla has requested that
> > the
> > action items be completed by the end of October 2009. If the action
> > items are
> > not completed within this timeframe, Mozilla plans to turn off the
> > trust bits
> > for this root (essentially disabling it)."
> >
> > Your move.
> >
> > P.S. Yes, I work for a competitor CA so I am probably biased. But
> > ipsCA
> > really do need to do better than this!
> >
> > On Wednesday 21 October 2009 19:41:53 Kathleen Wilson wrote:
> > > _______________________________________________
> > > dev-security-policy mailing list
> > > dev-secur...@lists.mozilla.org
> > > https://lists.mozilla.org/listinfo/dev-security-policy
> >
> > Rob Stradling
> > Senior Research & Development Scientist
> > C.O.M.O.D.O - Creating Trust Online
> > Office Tel: +44.(0)1274.730505
> > Office Fax: +44.(0)1274.730909
> > www.comodo.com
> >
> > Comodo CA Limited, Registered in England No. 04058690
> > Registered Office:
> > 3rd Floor, 26 Office Village, Exchange Quay,
> > Trafford Road, Salford, Manchester M5 3EQ
> >
> > This e-mail and any files transmitted with it are confidential and
> > intended
> > solely for the use of the individual or entity to whom they are
> > addressed.
> > If you have received this email in error please notify the sender by
> > replying
> > to the e-mail containing this attachment. Replies to this email may be
> > monitored by Comodo for operational or business reasons. Whilst every
> > endeavour is taken to ensure that e-mails are free from viruses, no
> > liability
> > can be accepted and the recipient is requested to use their own virus
> > checking
> > software.
> > _______________________________________________
> > dev-security-policy mailing list
> > dev-secur...@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-security-policy
> >
> > _______________________________________________________________________
> > Ezt az e-mailt virus- es SPAM-szuresnek vetettuk ala a filter:mail
> > MessageLabs rendszerrel. Tovabbi informacio: http://www.filtermax.hu
> >
> > This email has been scanned for viruses and SPAM by the filter:mail
> > MessageLabs System. More information: http://www.filtermax.hu
> > _______________________________________________________________________
> > _
>
> _______________________________________________________________________
> Ezt az e-mailt virus- es SPAM-szuresnek vetettuk ala a filter:mail
> MessageLabs rendszerrel. Tovabbi informacio: http://www.filtermax.hu
>
> This email has been scanned for viruses and SPAM by the filter:mail
> MessageLabs System. More information: http://www.filtermax.hu
> __________________________________________________________________________
> ______________
>
>
>
>
Eddy Nigg
> I'll have to go a bit off-topic (for this list) to back up that statement...
>
To make this a little bit more ON-topic....
> There are other side effects of their OCSP Responder returning "unknown"
> instead of "revoked" for Moxie's fake www.paypal.com certificate. Certain
> platforms (e.g. Internet Explorer and other Microsoft CryptoAPI-based
> applications on Windows Vista/7) prefer OCSP to CRL.
Mozilla Firefox will ONLY look at the OCSP responder and not even check
the CRL, never mind the response. An unknown response will result in the
user to accessing a fraudulent web site.
> Until a few days ago,
> these platforms would have noticed that IPS's OCSP Responder was unavailable
> and then checked IPS's CRL and found Moxie's certificate to be revoked.
> Today, these platforms will check IPS's OCSP Responder and find Moxie's
> certificate to be unrevoked (and they won't check IPS's CRL)!
Neither does Mozilla.
Rob Stradling
same for Mozilla browsers, but worsened for Windows CryptoAPI
applications/users.
And it's only because it's worsened for Windows CryptoAPI applications/users
that I suggested that ipsCA should switch off their OCSP Responder until
they've managed to really fix it. If nothing had worsened, there would be no
advantage to switching it off.
On Tuesday 03 November 2009 13:17:43 Eddy Nigg wrote:
> On 11/03/2009 09:25 AM, Rob Stradling:
> > I'll have to go a bit off-topic (for this list) to back up that
> > statement...
>
> To make this a little bit more ON-topic....
>
> > There are other side effects of their OCSP Responder returning "unknown"
> > instead of "revoked" for Moxie's fake www.paypal.com certificate.
> > Certain platforms (e.g. Internet Explorer and other Microsoft
> > CryptoAPI-based applications on Windows Vista/7) prefer OCSP to CRL.
>
> Mozilla Firefox will ONLY look at the OCSP responder and not even check
> the CRL, never mind the response. An unknown response will result in the
> user to accessing a fraudulent web site.
>
> > Until a few days ago,
> > these platforms would have noticed that IPS's OCSP Responder was
> > unavailable and then checked IPS's CRL and found Moxie's certificate to
> > be revoked. Today, these platforms will check IPS's OCSP Responder and
> > find Moxie's certificate to be unrevoked (and they won't check IPS's
> > CRL)!
>
> Neither does Mozilla.
>
Rob Stradling
David E. Ross
[snip]
>
> Rob Stradling
> Senior Research & Development Scientist
> C�O�M�O�D�O - Creating Trust Online
> Office Tel: +44.(0)1274.730505
> Office Fax: +44.(0)1274.730909
> www.comodo.com
>
> Comodo CA Limited, Registered in England No. 04058690
> Registered Office:
> 3rd Floor, 26 Office Village, Exchange Quay,
> Trafford Road, Salford, Manchester M5 3EQ
>
> This e-mail and any files transmitted with it are confidential and intended
> solely for the use of the individual or entity to whom they are addressed.
> If you have received this email in error please notify the sender by replying
> to the e-mail containing this attachment. Replies to this email may be
> monitored by Comodo for operational or business reasons. Whilst every
> endeavour is taken to ensure that e-mails are free from viruses, no liability
> can be accepted and the recipient is requested to use their own virus checking
> software.
Check your signature! (See above.) You indicate that the content is
restricted, but your message is broadcast to the whole world.
Eddy Nigg
> Check your signature! (See above.) You indicate that the content is
> restricted, but your message is broadcast to the whole world.
>
>
Funny, I was thinking exactly the same thing as well....but hadn't had
the time for a better suggestion (like either encrypt or remove the
meaningless notice). :-)
David E. Ross
>> Check your signature! (See above.) You indicate that the content is
>> restricted, but your message is broadcast to the whole world.
>>
>>
>
> Funny, I was thinking exactly the same thing as well....but hadn't had
> the time for a better suggestion (like either encrypt or remove the
> meaningless notice). :-)
>
Sometimes, I receive a message with a warning similar to the following:
> CONFIDENTIALLY NOTICE: This e-mail communication and any
> attachments may contain confidential and privileged information
> for the use of the designated recipients named above. Any
> unauthorized review, use, disclosure or distribution is prohibited.
> If you are not the intended recipient, please contact the sender by
> reply e-mail and destroy all copies of the original message.
This warning is meaningless. First of all, "confidential and privileged
information" should be encrypted before sending over the Internet.
Furthermore, this prohibition cannot be enforced. If someone sent a
restricted message to me by mistake, that is their error for which they
must suffer the consequences. They cannot foist blame onto me for their
mistake when I disclose the message to others.
No, I do not disclose the content of encrypted messages that I receive
unless the sender and I both agree. Unencrypted messages, however, have
the same protection against disclosure as does a post card sent through
the US Postal Service.
Rob Stradling
> On 11/3/2009 5:26 AM, Rob Stradling wrote:
> [snip]
>
> Check your signature! (See above.) You indicate that the content is
> restricted, but your message is broadcast to the whole world.
Thanks David. That's a good point. I will refrain from appending that text
to any future posts I make to Mozilla mailing lists.
Varga Viktor
What is the decision?
Will be there strong deadlines for actions?
For example:
"a reported bug should be resolved in a week, and there is an optional one week period by request
the request should be posted to the dev.tech.crypto, and should include a cause"
(for example: we need one more week, because a meteor destroyed the city)
Another question:
Is/Will be there some "fast update" mechnism for these info for Mozilla products? Like the MS Crypt32, who checks to the MS servers for CA info? (for example a CA trust list signed by the mozilla?)
Üdvözlettel/Regards,
Varga Viktor
Üzemeltetési és Vevőszolgálati Vezető
IT Service and Customers Service Executive
Netlock Kft.
> -----Original Message-----
> From: dev-security-policy-bounces+varga_v=netlo...@lists.mozilla.org
> [mailto:dev-security-policy-
> bounces+varga_v=netlo...@lists.mozilla.org] On Behalf Of Rob
> Stradling
> Sent: Wednesday, November 04, 2009 9:24 AM
> To: dev-secur...@lists.mozilla.org
> Cc: David E. Ross
> Subject: Re: Resolving concerns about the IPS SERVIDORES root
> certificate
>
> On Tuesday 03 November 2009 15:45:32 David E. Ross wrote:
> > On 11/3/2009 5:26 AM, Rob Stradling wrote:
> > [snip]
> > > This e-mail and any files transmitted with it are confidential and
> <snip>
> >
> > Check your signature! (See above.) You indicate that the content is
> > restricted, but your message is broadcast to the whole world.
>
> Thanks David. That's a good point. I will refrain from appending that
> text
> to any future posts I make to Mozilla mailing lists.
>
> Rob Stradling
> Senior Research & Development Scientist
> C.O.M.O.D.O - Creating Trust Online
Kathleen Wilson
bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=523652
Kyle Hamilton
doesn't want to run a CA. (More specifically, it doesn't want to "be
in the PKI business", even though it already is through this
vetting/approval process.)
-Kyle H
2009/11/4 Varga Viktor <var...@netlock.hu>:
>> > On 11/3/2009 5:26 AM, Rob Stradling wrote:
>> > [snip]
>> > > This e-mail and any files transmitted with it are confidential and
>> <snip>
>> >
>> > Check your signature! (See above.) You indicate that the content is
>> > restricted, but your message is broadcast to the whole world.
>>
>> Thanks David. That's a good point. I will refrain from appending that
>> text
>> to any future posts I make to Mozilla mailing lists.
>>
>> Rob Stradling
>> Senior Research & Development Scientist
Varga Viktor
We will issue a certificate for the Mozilla, if the Mozilla needs.
It's of-course free. :)
Üdvözlettel/Regards,
Varga Viktor
Üzemeltetési és Vevőszolgálati Vezető
IT Service and Customers Service Executive
Netlock Kft.
> -----Original Message-----
> From: Kyle Hamilton [mailto:aero...@gmail.com]
> Sent: Wednesday, November 11, 2009 12:51 AM
> To: Varga Viktor
> Cc: Rob Stradling; dev-secur...@lists.mozilla.org
> Subject: Re: Resolving concerns about the IPS SERVIDORES root
> certificate
>
> >> > On 11/3/2009 5:26 AM, Rob Stradling wrote:
> >> > [snip]
> >> > > This e-mail and any files transmitted with it are confidential
> and
> >> <snip>
> >> >
> >> > Check your signature! (See above.) You indicate that the content
> is
> >> > restricted, but your message is broadcast to the whole world.
> >>
> >> Thanks David. That's a good point. I will refrain from appending
> that
> >> text
> >> to any future posts I make to Mozilla mailing lists.
> >>
> >> Rob Stradling
> >> Senior Research & Development Scientist
Eddy Nigg
> The latest status of the IPS OCSP responder has been posted in the
> bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=523652
>
A comment just has been posted:
https://bugzilla.mozilla.org/show_bug.cgi?id=523652#c8
What were the action items supposed to be at the end of October, three
month after the null line ending bug has been published?
=JeffH
>
> A comment just has been posted:
> https://bugzilla.mozilla.org/show_bug.cgi?id=523652#c8
>
> What were the action items supposed to be at the end of October, three
> month after the null line ending bug has been published?
indeed, I posted the comment yesterday after a modicum of review of this
thread, the bug comments <https://bugzilla.mozilla.org/show_bug.cgi?id=523652>,
as well as poking at IPS Servidores et al's ocsp responders (via openssl).
Below is the text of the comment I added, fyi/fwiw.
=JeffH
-------------------------------------------
=JeffH 2009-11-18 17:24:11 PST
FYI/FWIW and just as a data point, I attempted some manual OCSP queries to
various of the IPS SERVIDORES ocsp DNS names (ocsp.ips.es -> ips.certiver.com
-> ocsp.ipsca.com) today 18-Nov-2009 between the hours of approx 1500h PST and
1630h PST, and consistently received a response of either..
"error:27070072:OCSP routines:OCSP_sendreq_bio:server response
error:ocsp_ht.c:147:Code=403,Reason=Forbidden ( The server denied the specified
Uniform Resource Locator (URL). Contact the server administrator. ) "
..or the query hung forever (and eventually timed out) and I never received a
response. I tried from two different machines on the internet, and i tried
using both "http" and "httpS" URLs.
I don't have time right now to examine my test results in detail, but it seems
the connection timeouts were (only) when trying to use an "httpS" OCSP URL
(yes, I know that the URLs given in the AIA field of the certs is an "http"
one, but the IPS ocsp service used to answer on https for whatever reason back
in Oct-2009). The above error:27070072 appears to be returned consistently for
ocsp queries using "http" URLs.
Hope this helps.
--------------------------------------------
Eddy Nigg
> > What were the action items supposed to be at the end of October, three
> > month after the null line ending bug has been published?
>
> indeed, I posted the comment yesterday after a modicum of review of
> this thread, the bug comments
> <https://bugzilla.mozilla.org/show_bug.cgi?id=523652>, as well as
> poking at IPS Servidores et al's ocsp responders (via openssl).
Thanks for following up on this.
> ...or the query hung forever (and eventually timed out) and I never
> received a
> response. I tried from two different machines on the internet, and i
> tried
> using both "http" and "httpS" URLs.
There is no point in checking anything else than what's in the AIA
extension.
> in Oct-2009). The above error:27070072 appears to be returned
> consistently for
> ocsp queries using "http" URLs.
Error 27070072 appears to be 404, Not Found
=JeffH
> extension.
sure, from a "what a user agent is supposed to do in real life" perspective.
But I was/am curious wrt the overall breakage at the IPS site(s) 8^)
> Error 27070072 appears to be 404, Not Found
well, fwiw, it appears the full error msg text (that I am issued) indicates
it's actually "403, Forbidden"...
error:27070072:OCSP routines:OCSP_sendreq_bio:server response
error:ocsp_ht.c:147:Code=403,Reason=Forbidden ( The server denied the specified
Uniform Resource Locator (URL). Contact the server administrator. )
=JeffH
Eddy Nigg
IIRC the affected root is supposed to expire in the next two weeks or
so. There is obviously not much point to act on that root, but what
about all the others? Again IIRC they use the same URI in the AIA
extensions?
Kathleen Wilson
> bug:https://bugzilla.mozilla.org/show_bug.cgi?id=523652
The OCSP responder issues for the IPS SERVIDORES root have been
confirmed to be resolved.
Bug #523652 has been closed as fixed.
Rob Stradling
Kathleen, I still get an HTTP 403 error from ipsCA's OCSP Responder.
Has anybody independently confirmed that the problems are resolved?
Or have you just taken ipsCA's word for it so far?
Thanks.
Rob Stradling
Senior Research & Development Scientist
Eddy Nigg
> On Tuesday 24 November 2009 19:16:09 Kathleen Wilson wrote:
>
>>> The latest status of the IPS OCSP responder has been posted in the
>>> bug:https://bugzilla.mozilla.org/show_bug.cgi?id=523652
>>>
>> The OCSP responder issues for the IPS SERVIDORES root have been
>> confirmed to be resolved.
>>
>> Bug #523652 has been closed as fixed.
>>
> Kathleen, I still get an HTTP 403 error from ipsCA's OCSP Responder.
>
> Has anybody independently confirmed that the problems are resolved?
> Or have you just taken ipsCA's word for it so far?
>
>
Kathleen, did you set OCSP validation to a hard failure in case no
response is received? Did you check that the certificate of the site you
are visiting has the AIA OCSP URI has found previously?
Gervase Markham
> Kathleen, I still get an HTTP 403 error from ipsCA's OCSP Responder.
Not picking on Rob, but can people reporting failures please report
details of the request sent, the response received, the time at which
the request was made, and (ideally) the elapsed time taken to get a
response?
It would also help, if people are interested in monitoring ipsCA's OCSP
server, if they were to perform regular repeatable tests rather than
one-offs, and then provide statistical data.
> Has anybody independently confirmed that the problems are resolved?
> Or have you just taken ipsCA's word for it so far?
We have been doing some testing of our own.
Gerv
Nelson Bolyard
> On 25/11/09 08:18, Rob Stradling wrote:
>> Kathleen, I still get an HTTP 403 error from ipsCA's OCSP Responder.
>
> Not picking on Rob, but can people reporting failures please report
> details of the request sent, the response received, the time at which
> the request was made, and (ideally) the elapsed time taken to get a
> response?
>
> It would also help, if people are interested in monitoring ipsCA's OCSP
> server, if they were to perform regular repeatable tests rather than
> one-offs, and then provide statistical data.
All tests done between 0500 and 2300 PST Monday succeeded.
The distribution of response times was
num seconds (rounded down)
--- ---
51 0
75 1
2 3
4 4
2 7
5 8
8 9
30 10
18 11
7 12
5 13
2 14
3 15
1 16
For the almost 24 hour period from 2300 PST Monday until 2210 PST Tuesday
(at which point I stopped the test), the results were:
269 successes (97.1%)
8 failures
of which
7 unexpected/invalid HTTP data (e.g. a 403 error)
1 was a failure to get a proper OCSP response (may have been a timeout)
response time distribution
12 0
184 1
2 2
3 3
6 4
3 5
3 6
8 7
4 8
6 9
9 10
12 11
8 12
4 13
1 14
5 15
2 16
5 21
--
12345678901234567890123456789012345678901234567890123456789012345678901234567890
00000000011111111112222222222333333333344444444445555555555666666666677777777778
=JeffH
and wget. 100% fail so far (just a handful of requests). I began approx 1230h
PST and it's now 1300h PST.
=JeffH
e.g. some attempts in the last few minutes..
> date; wget http://ocsp.ipsca.com/ ; date
Wed Nov 25 13:55:36 MST 2009
--13:55:36-- http://ocsp.ipsca.com/
=> `index.html.1'
Resolving ocsp.ipsca.com... 213.139.30.155, 195.78.229.167, 195.78.229.168, ...
Connecting to ocsp.ipsca.com|213.139.30.155|:80... connected.
HTTP request sent, awaiting response... 404 Not Found ( The requested item
could not be located. )
13:55:57 ERROR 404: Not Found ( The requested item could not be located. ).
Wed Nov 25 13:55:57 MST 2009
> date; openssl ocsp -issuer ./IPSCACLASEA1.crt -CAfile ./IPS-IPSCABUNDLE.crt
-VAfile ./IPS-IPSCABUNDLE.crt -cert
./Marlinspike-NullPrefix-www.PayPal.com-Cert-2009-09-29.pem -url
http://ocsp.ipsca.com/ -resp_text -req_text; date
Wed Nov 25 13:57:14 MST 2009
OCSP Request Data:
Version: 1 (0x0)
Requestor List:
Certificate ID:
Hash Algorithm: sha1
Issuer Name Hash: 071F5D05B88ABF4C731DDC251527E11639F7433B
Issuer Key Hash: 0E0760D439C91B5B5D907B23C8D2349D4A9A4639
Serial Number: F09B
Request Extensions:
OCSP Nonce:
041056ADFEA520F58054F645881438F7742F
Error querying OCSP responsder
9004:error:27070072:OCSP routines:OCSP_sendreq_bio:server response
error:ocsp_ht.c:147:Code=403,Reason=Forbidden ( The server denied the specified
Uniform Resource Locator (URL). Contact the server administrator. )
Wed Nov 25 13:57:15 MST 2009
> date; wget http://ocsp.ipsca.com/ ; date
Wed Nov 25 13:57:23 MST 2009
--13:57:23-- http://ocsp.ipsca.com/
=> `index.html.1'
Resolving ocsp.ipsca.com... 213.139.30.155, 195.78.229.167, 195.78.229.168, ...
Connecting to ocsp.ipsca.com|213.139.30.155|:80... connected.
HTTP request sent, awaiting response... 400 Bad Request
13:57:23 ERROR 400: Bad Request.
Wed Nov 25 13:57:23 MST 2009
---
end
Rob Stradling
> On 25/11/09 08:18, Rob Stradling wrote:
> > Kathleen, I still get an HTTP 403 error from ipsCA's OCSP Responder.
>
> Not picking on Rob, but can people reporting failures please report
> details of the request sent, the response received, the time at which
> the request was made, and (ideally) the elapsed time taken to get a
> response?
Sorry Gerv. Initially, I just wanted to know if anyone had independently
verified any non-failures since ipsCA reported that they'd fixed everything.
Thank you (and Nelson) for confirming that you have verified some non-
failures.
I've just tested it again and got the same HTTP 403 response.
$ echo && date && echo && time openssl ocsp -issuer
ipsCACLASEA1CertificationAuthority.crt -cert moxie_paypal.crt -no_nonce -url
http://ocsp.ipsca.com -noverify
Thu Nov 26 07:29:27 GMT 2009
Error querying OCSP responsder
8499:error:27075072:OCSP routines:PARSE_HTTP_LINE1:server response
error:ocsp_ht.c:224:Code=403,Reason=Forbidden ( The server denied the
specified Uniform Resource Locator (URL). Contact the server administrator. )
real 0m0.387s
user 0m0.000s
sys 0m0.010s
> It would also help, if people are interested in monitoring ipsCA's OCSP
> server, if they were to perform regular repeatable tests rather than
> one-offs, and then provide statistical data.
>
> > Has anybody independently confirmed that the problems are resolved?
> > Or have you just taken ipsCA's word for it so far?
>
> We have been doing some testing of our own.
>
> Gerv
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
Rob Stradling
Senior Research & Development Scientist
C·O·M·O·D·O - Creating Trust Online
Gervase Markham
> I have been poking at http://ocsp.ipsca.com/ today by hand via openssl,
> lynx, and wget. 100% fail so far (just a handful of requests). I began
> approx 1230h PST and it's now 1300h PST.
Why would you expect random wgets of the root URL to work? The only
interesting thing is its response to properly-formed OSCP queries.
Having made that point, the queries you list later in your message look
more like the right sort of thing (to my untrained eye).
Gerv
Nelson Bolyard
> I've just tested it again and got the same HTTP 403 response.
>
> $ echo && date && echo && time openssl ocsp -issuer
> ipsCACLASEA1CertificationAuthority.crt -cert moxie_paypal.crt -no_nonce -url
> http://ocsp.ipsca.com -noverify
>
> Thu Nov 26 07:29:27 GMT 2009
>
> Error querying OCSP responsder
> 8499:error:27075072:OCSP routines:PARSE_HTTP_LINE1:server response
> error:ocsp_ht.c:224:Code=403,Reason=Forbidden ( The server denied the
> specified Uniform Resource Locator (URL). Contact the server administrator. )
>
> real 0m0.387s
> user 0m0.000s
> sys 0m0.010s
I wonder... maybe openssl ocsp does an http GET?
The tests I did use http POST.
Maybe that explains the difference?
Rob Stradling
> On 2009-11-26 00:10 PST, Rob Stradling wrote:
> > I've just tested it again and got the same HTTP 403 response.
> I wonder... maybe openssl ocsp does an http GET?
> The tests I did use http POST.
> Maybe that explains the difference?
Aha! Yes, that's it. This works for me...
$ openssl ocsp -issuer ipsCACLASEA1CertificationAuthority.crt -cert
moxie_paypal.crt -reqout moxie_paypal.orq
$ wget --post-file=moxie_paypal.orq -O moxie_paypal.ors --header="Content-
Type: application/ocsp-request" http://ocsp.ipsca.com
$ openssl ocsp -issuer ipsCACLASEA1CertificationAuthority.crt -respin
moxie_paypal.ors -noverify -resp_text
I notice that ipsCA's OCSP Signing Certificate is valid for another 11 months,
but only has a 512-bit RSA key. I believe that it's already feasible to crack
that key size well within that timeframe.
Eddy Nigg
> Aha! Yes, that's it. This works for me...
>
> $ openssl ocsp -issuer ipsCACLASEA1CertificationAuthority.crt -cert
> moxie_paypal.crt -reqout moxie_paypal.orq
> $ wget --post-file=moxie_paypal.orq -O moxie_paypal.ors --header="Content-
> Type: application/ocsp-request" http://ocsp.ipsca.com
> $ openssl ocsp -issuer ipsCACLASEA1CertificationAuthority.crt -respin
> moxie_paypal.ors -noverify -resp_text
>
> I notice that ipsCA's OCSP Signing Certificate is valid for another 11 months,
> but only has a 512-bit RSA key. I believe that it's already feasible to crack
> that key size well within that timeframe.
>
>
Their CA root is about to expire and the other roots were requested to
be removed. I believe that it doesn't matter if the OCSP responders work
or what key sizes they are using. We'll keep that in mind for their
inclusion request of the new roots however.
Varga Viktor
Üdvözlettel/Regards,
Varga Viktor
Üzemeltetési és Vevőszolgálati Vezető
IT Service and Customers Service Executive
Netlock Kft.
> -----Original Message-----
> From: dev-security-policy-bounces+varga_v=netlo...@lists.mozilla.org
> [mailto:dev-security-policy-
> bounces+varga_v=netlo...@lists.mozilla.org] On Behalf Of Nelson
> Bolyard
> Sent: Friday, November 27, 2009 8:24 AM
> To: dev-secur...@lists.mozilla.org
> Subject: Re: Resolving concerns about the IPS SERVIDORES root
> certificate
>
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
Rob Stradling
> The openssl OCSP can use POST method, because i am testing our OCSP with
> openssl, if i need.
Ah, you're right Varga. "openssl ocsp" does use POST, not GET. I'd jumped to
the wrong conclusion.
I've found the real cause of the problem. "openssl ocsp" doesn't specify the
"Host" HTTP header, and ocsp.ipsca.com seems to require it to be specified.
The openssl-1.0.0-beta4 version of "openssl ocsp" allows custom HTTP headers
to be specified. This works...
$ ~/local/openssl-1.0.0-beta4/bin/openssl ocsp -issuer
ipsCACLASEA1CertificationAuthority.crt -cert moxie_paypal.crt -no_nonce -url
http://ocsp.ipsca.com -noverify -header Host ocsp.ipsca.com
moxie_paypal.crt: revoked
This Update: Nov 27 11:01:11 2009 GMT
Revocation Time: Aug 3 13:44:20 2009 GMT
(The openssl-1.0.0-beta CHANGES file says...
" Changes between 0.9.8k and 1.0 [xx XXX xxxx]
<snip>
*) Update OCSP request code to permit adding custom headers to the request:
some responders need this.
[Steve Henson]")
> Üdvözlettel/Regards,
>
> Varga Viktor
> Üzemeltetési és Vevőszolgálati Vezető
> IT Service and Customers Service Executive
> Netlock Kft.
>
> > -----Original Message-----
> > From: dev-security-policy-bounces+varga_v=netlo...@lists.mozilla.org
> > [mailto:dev-security-policy-
> > bounces+varga_v=netlo...@lists.mozilla.org] On Behalf Of Nelson
> > Bolyard
> > Sent: Friday, November 27, 2009 8:24 AM
> > To: dev-secur...@lists.mozilla.org
> > Subject: Re: Resolving concerns about the IPS SERVIDORES root
> > certificate
> >
> > _______________________________________________
> > dev-security-policy mailing list
> > dev-secur...@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-security-policy
> >
> > _______________________________________________________________________
> > Ezt az e-mailt virus- es SPAM-szuresnek vetettuk ala a filter:mail
> > MessageLabs rendszerrel. Tovabbi informacio: http://www.filtermax.hu
> >
> > This email has been scanned for viruses and SPAM by the filter:mail
> > MessageLabs System. More information: http://www.filtermax.hu
> > _______________________________________________________________________
> > _
>
> _______________________________________________________________________
> Ezt az e-mailt virus- es SPAM-szuresnek vetettuk ala a filter:mail
> MessageLabs rendszerrel. Tovabbi informacio: http://www.filtermax.hu
>
> This email has been scanned for viruses and SPAM by the filter:mail
> MessageLabs System. More information: http://www.filtermax.hu
> __________________________________________________________________________
> ______________ _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
Rob Stradling
Senior Research & Development Scientist
C·O·M·O·D·O - Creating Trust Online
Nelson Bolyard
> On Friday 27 November 2009 10:38:20 Varga Viktor wrote:
>> The openssl OCSP can use POST method, because i am testing our OCSP with
>> openssl, if i need.
>
> Ah, you're right Varga. "openssl ocsp" does use POST, not GET. I'd jumped to
> the wrong conclusion.
>
> I've found the real cause of the problem. "openssl ocsp" doesn't specify the
> "Host" HTTP header, and ocsp.ipsca.com seems to require it to be specified.
Hmm. If correct, that implies that NSS's built-in http client must send a
Host header in the http requests. That would surprise me, somewhat.
I'll have to check.