Re: OCSP Requirement - ipsCA
=JeffH
> both of these certificates as having been revoked on August 3rd 13:44:20 2009
> GMT.
>
>> This CA appears to have an OCSP responder and even included the URL in the
>> certificates (http://ocsp.ipsca.com/), unfortunately the responder is
>> non-compliant.
>
> So it seems. The only response I can get from ipsCA's OCSP Responder is HTTP
> 403 (Forbidden).
Just fwiw, apparently part of the reason the OCSP responder fails is that its
URI is really supposed to be "httpS". Making that change, their OCSP service
will respond.
=JeffH
Eddy Nigg
I tried that and it doesn't work for me, https://ocsp.ipsca.com/ gives
"Firefox can't find the server at ocsp.ipsca.com"
Even if it would work with https:// , that in itself is such an
incredible stupid idea, simply a testimony of PKI not understood. CRLs
and OCSP responses are signed, there is no benefit for serving them over
SSL/TLS. It would work in theory if the SSL connection would be secured
by a DIFFERENT CA because otherwise it would fail to confirm its own
certificate status. Using a different CA for securing a CRL or OCSP
response bears the risk when the other CAs services would be down. And
what about the OTHER CA's revocation status? Also over SSL/TLS? In
short, NEVER do that...
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
Ian G
> On 10/10/2009 12:56 AM, =JeffH:
>> Just fwiw, apparently part of the reason the OCSP responder fails is
>> that its URI is really supposed to be "httpS". Making that change,
>> their OCSP service will respond.
> Even if it would work with https:// , that in itself is such an
> incredible stupid idea, simply a testimony of PKI not understood. CRLs
> and OCSP responses are signed, there is no benefit for serving them over
> SSL/TLS.
Er.. privacy? traffic monitoring? All yur visits belong to us?
I grant PKI is not understood, but does PKI understand? Is it the
mission of PKI to create centralised opportunities of users' browsing
habits?
> It would work in theory if the SSL connection would be secured
> by a DIFFERENT CA because otherwise it would fail to confirm its own
> certificate status. Using a different CA for securing a CRL or OCSP
> response bears the risk when the other CAs services would be down. And
> what about the OTHER CA's revocation status? Also over SSL/TLS? In
> short, NEVER do that...
Clearly, a better understanding of the protocols leaves one thinking
"don't do that." But it also leaves one wondering more broadly, like
... "don't do that!"
iang
PS: as it happens, CAcert set up is OCSP using HTTPS, because of privacy
concerns, *of course*. Now there is some discussion going on about
removing the recursion in certain browsers, and whether we have to
discard the privacy just to get it working.
=JeffH
>
> Eddy Nigg stated:
>
>> Even if it would work with https:// , that in itself is such an
>> incredible stupid idea, simply a testimony of PKI not understood. CRLs
>> and OCSP responses are signed, there is no benefit for serving them over
>> SSL/TLS.
>
> Er.. privacy? traffic monitoring? All yur visits belong to us?
Agreed. There's all sorts of reasons to use a secure connection even if
message-level security (integrity and data-origin authn in this case) is being
employed.
But, that is besides the point from the actual operational perspective in this
case. ipsCA issued bogus certs which had bogus OCSP pointers in them (for
whatever reason).
Also, regardless of the cert and CA used to secure the TLS/SSL transport, I
found the various aspects of the cert used to sign the OCSP response to be
broken (URIs that yielded 404s, including the URI pointing to where to get the
cert to use to validat the signature on the OSCP response message (Authority
Information Access), not to mention that they indicate(d) the status of the
bogus null-prefix certificate is only "unknown" -- see below).
> Eddy Nigg had also stated:
>
>> I tried that and it doesn't work for me, https://ocsp.ipsca.com/ gives
>> "Firefox can't find the server at ocsp.ipsca.com"
Innaresting & curious. It'd worked for me earlier this week (using openssl).
Apparently the DNS record for "ocsp.ipsca.com" went away in the last day or so..
> host -a ocsp.ipsca.com
Trying "ocsp.ipsca.com"
Host ocsp.ipsca.com not found: 3(NXDOMAIN)
=JeffH
------
> openssl ocsp -issuer ./IPSCACLASEA1.crt -CAfile ./IPS-IPSCABUNDLE.crt
-VAfile ./IPS-IPSCABUNDLE.crt -cert
Marlinspike-NullPrefixWildcardCert-2009-09-29.pem -url https://ocsp.ipsca.com/
-resp_text -req_text
OCSP Request Data:
Version: 1 (0x0)
Requestor List:
Certificate ID:
Hash Algorithm: sha1
Issuer Name Hash: 071F5D05B88ABF4C731DDC251527E11639F7433B
Issuer Key Hash: 0E0760D439C91B5B5D907B23C8D2349D4A9A4639
Serial Number: 13179F
Request Extensions:
OCSP Nonce:
0410E7E61B4EFD3456D01C41E97FB60A7394
OCSP Response Data:
OCSP Response Status: successful (0x0)
Response Type: Basic OCSP Response
Version: 1 (0x0)
Responder Id: O = , CN = OCSP, emailAddress = m.p...@ipsca.com, UID = 123123
Produced At: Oct 8 21:42:24 2009 GMT
Responses:
Certificate ID:
Hash Algorithm: sha1
Issuer Name Hash: 071F5D05B88ABF4C731DDC251527E11639F7433B
Issuer Key Hash: 0E0760D439C91B5B5D907B23C8D2349D4A9A4639
Serial Number: 13179F
Cert Status: unknown
This Update: Oct 8 21:42:24 2009 GMT
Response Extensions:
OCSP Nonce:
0410E7E61B4EFD3456D01C41E97FB60A7394
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 4123 (0x101b)
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=FR, ST=Paris, L=Paris, O=Document Channel, OU=Certificates,
CN=Document Channel ipsCA CA/emailAddress=DC...@ipsCA.com
Validity
Not Before: Jun 16 11:38:36 2009 GMT
Not After : Jun 16 11:38:36 2011 GMT
Subject: O=, CN=OCSP/emailAddress=m.p...@ipsca.com/UID=123123
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:e2:63:16:4f:42:69:80:70:4b:ab:95:2c:24:32:
5a:a7:97:04:00:3e:ed:ed:4f:83:dc:dc:a5:63:e3:
6c:73:bf:04:41:27:8f:26:13:38:72:4b:fa:92:e1:
7a:bd:0c:55:da:e3:7f:5d:93:f9:b8:78:c7:b7:35:
47:1e:ed:eb:af:4c:bc:d3:a3:f4:06:7b:09:b4:4f:
9b:82:42:f8:ff:a1:e3:71:06:af:a5:93:ce:9b:5f:
13:81:f3:db:94:f4:7f:f7:3e:75:67:af:8e:79:d7:
f8:f5:c6:b6:5a:bb:26:9c:f9:7e:9f:fe:62:b7:62:
27:01:48:88:5f:80:d0:2c:cb
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Cert Type:
SSL Client, SSL Server, S/MIME
X509v3 Key Usage:
Digital Signature, Non Repudiation, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Client Authentication, E-mail Protection
X509v3 Subject Key Identifier:
00:A6:3A:A3:B0:15:64:B3:0D:F8:77:0E:7A:9F:7E:74:AA:E2:A3:4F
X509v3 Authority Key Identifier:
keyid:DA:AB:56:AD:D2:45:61:B4:CB:79:7E:40:28:DF:C1:4C:9A:FB:9E:88
Netscape Comment:
Certificate issued by Document Channel CA
Netscape Base Url:
http://documentchannel.ipsca.com/
Netscape CA Revocation Url:
http://documentchannel.ipsca.com/crl/dcca.crl
Netscape Revocation Url:
http://documentchannel.ipsca.com/revocation.html?
Netscape Renewal Url:
http://documentchannel.ipsca.com/renewal.html?
Netscape CA Policy Url:
http://documentchannel.ipsca.com/policy.html
X509v3 CRL Distribution Points:
URI:http://documentchannel.ipsca.com/crl/DCCA.crl
URI:http://documentchannel02.ipsca.com/crl/DCCA.crl
Authority Information Access:
CA Issuers - URI:http://documentchannel.ipsca.com/DCCAestado.html
Signature Algorithm: sha1WithRSAEncryption
f5:32:5d:82:b0:1e:6a:1e:8a:97:59:f5:39:98:9f:7a:dd:d1:
fd:7c:45:df:03:49:da:bd:15:17:bc:67:c5:77:68:88:ae:27:
64:8b:55:0d:44:c5:63:2d:db:fe:80:e2:6b:a6:7c:66:03:28:
08:45:d7:fc:d6:78:d2:44:bb:89:6c:63:75:f8:4f:43:21:60:
3a:8d:8f:e2:8b:56:ff:dd:df:58:1b:97:b7:30:39:18:f1:2e:
16:d4:e9:4f:cf:58:bf:29:d9:47:33:27:79:88:2c:9b:4a:46:
a0:0e:82:66:2b:8f:bf:2d:5c:2a:a8:29:10:1a:0e:ba:39:33:
a6:b8
-----BEGIN CERTIFICATE-----
MIIFKzCCBJSgAwIBAgICEBswDQYJKoZIhvcNAQEFBQAwgaIxCzAJBgNVBAYTAkZS
MQ4wDAYDVQQIEwVQYXJpczEOMAwGA1UEBxMFUGFyaXMxGTAXBgNVBAoTEERvY3Vt
ZW50IENoYW5uZWwxFTATBgNVBAsTDENlcnRpZmljYXRlczEiMCAGA1UEAxMZRG9j
dW1lbnQgQ2hhbm5lbCBpcHNDQSBDQTEdMBsGCSqGSIb3DQEJARYORENDQUBpcHND
QS5jb20wHhcNMDkwNjE2MTEzODM2WhcNMTEwNjE2MTEzODM2WjBUMQkwBwYDVQQK
DAAxDTALBgNVBAMMBE9DU1AxIDAeBgkqhkiG9w0BCQEWEW0ucGVyZXpAaXBzY2Eu
Y29tMRYwFAYKCZImiZPyLGQBAQwGMTIzMTIzMIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQDiYxZPQmmAcEurlSwkMlqnlwQAPu3tT4Pc3KVj42xzvwRBJ48mEzhy
S/qS4Xq9DFXa439dk/m4eMe3NUce7euvTLzTo/QGewm0T5uCQvj/oeNxBq+lk86b
XxOB89uU9H/3PnVnr4551/j1xrZauyac+X6f/mK3YicBSIhfgNAsywIDAQABo4IC
uzCCArcwCQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBeAwCwYDVR0PBAQDAgXg
MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUAKY6o7AV
ZLMN+HcOep9+dKrio08wHwYDVR0jBBgwFoAU2qtWrdJFYbTLeX5AKN/BTJr7nogw
OAYJYIZIAYb4QgENBCsWKUNlcnRpZmljYXRlIGlzc3VlZCBieSBEb2N1bWVudCBD
aGFubmVsIENBMDAGCWCGSAGG+EIBAgQjFiFodHRwOi8vZG9jdW1lbnRjaGFubmVs
Lmlwc2NhLmNvbS8wPAYJYIZIAYb4QgEEBC8WLWh0dHA6Ly9kb2N1bWVudGNoYW5u
ZWwuaXBzY2EuY29tL2NybC9kY2NhLmNybDBABglghkgBhvhCAQMEMxYxaHR0cDov
L2RvY3VtZW50Y2hhbm5lbC5pcHNjYS5jb20vcmV2b2NhdGlvbi5odG1sPzA9Bglg
hkgBhvhCAQcEMBYuaHR0cDovL2RvY3VtZW50Y2hhbm5lbC5pcHNjYS5jb20vcmVu
ZXdhbC5odG1sPzA7BglghkgBhvhCAQgELhYsaHR0cDovL2RvY3VtZW50Y2hhbm5l
bC5pcHNjYS5jb20vcG9saWN5Lmh0bWwwdQYDVR0fBG4wbDAzoDGgL4YtaHR0cDov
L2RvY3VtZW50Y2hhbm5lbC5pcHNjYS5jb20vY3JsL0RDQ0EuY3JsMDWgM6Axhi9o
dHRwOi8vZG9jdW1lbnRjaGFubmVsMDIuaXBzY2EuY29tL2NybC9EQ0NBLmNybDBM
BggrBgEFBQcBAQRAMD4wPAYIKwYBBQUHMAKGMGh0dHA6Ly9kb2N1bWVudGNoYW5u
ZWwuaXBzY2EuY29tL0RDQ0Flc3RhZG8uaHRtbDANBgkqhkiG9w0BAQUFAAOBgQD1
Ml2CsB5qHoqXWfU5mJ963dH9fEXfA0navRUXvGfFd2iIridki1UNRMVjLdv+gOJr
pnxmAygIRdf81njSRLuJbGN1+E9DIWA6jY/ii1b/3d9YG5e3MDkY8S4W1OlPz1i/
KdlHMyd5iCybSkagDoJmK4+/LVwqqCkQGg66OTOmuA==
-----END CERTIFICATE-----
Response Verify Failure
19313:error:27069065:OCSP routines:OCSP_basic_verify:certificate verify
error:ocsp_vfy.c:122:Verify error:unable to get local issuer certificate
Marlinspike-NullPrefixWildcardCert-2009-09-29.pem: unknown
This Update: Oct 8 21:42:24 2009 GMT
---
end
Eddy Nigg
>
> Er.. privacy? traffic monitoring? All yur visits belong to us?
Who says that?
But the "privacy" argument is as brain-dead as the idea itself. Who do
you want to protect from whom really?
Whoever sniffs a users network already knows where he was heading by
just looking at the TCP/IP stream. There is no need to try to find out
by looking at the OCSP request which follows thereafter.
The CA knows also which site the user wants to visit, it answers the
very status request. What other privacy issue do you consider worth
breaking the certificate revocation status?
>
> I grant PKI is not understood, but does PKI understand? Is it the
> mission of PKI to create centralised opportunities of users' browsing
> habits?
>
>
Use CRLs instead of OCSP if you are so inclined, but don't serve either
CRLs nor OCSP over SSL/TLS please.
> PS: as it happens, CAcert set up is OCSP using HTTPS, because of
> privacy concerns, *of course*.
That's not surprising really.
> Now there is some discussion going on about removing the recursion
> in certain browsers, and whether we have to discard the privacy just
> to get it working.
That's perhaps already a good start with the wrong argument. What privacy?
Eddy Nigg
>
> Also, regardless of the cert and CA used to secure the TLS/SSL
> transport, I found the various aspects of the cert used to sign the
> OCSP response to be broken (URIs that yielded 404s, including the URI
> pointing to where to get the cert to use to validat the signature on
> the OSCP response message (Authority Information Access), not to
> mention that they indicate(d) the status of the bogus null-prefix
> certificate is only "unknown" -- see below).
>
> 19313:error:27069065:OCSP routines:OCSP_basic_verify:certificate
> verify error:ocsp_vfy.c:122:Verify error:unable to get local issuer
> certificate
> Marlinspike-NullPrefixWildcardCert-2009-09-29.pem: unknown
> This Update: Oct 8 21:42:24 2009 GMT
Perhaps even the CRL is issued by the wrong issuer - wouldn't surprise
me either.
Eddy Nigg
> On 10/11/2009 05:11 AM, =JeffH:
>>
>> Also, regardless of the cert and CA used to secure the TLS/SSL
>> transport, I found the various aspects of the cert used to sign the
>> OCSP response to be broken (URIs that yielded 404s, including the URI
>> pointing to where to get the cert to use to validat the signature on
>> the OSCP response message (Authority Information Access), not to
>> mention that they indicate(d) the status of the bogus null-prefix
>> certificate is only "unknown" -- see below).
>>
>> Response Verify Failure
>> 19313:error:27069065:OCSP routines:OCSP_basic_verify:certificate
>> verify error:ocsp_vfy.c:122:Verify error:unable to get local issuer
>> certificate
>> Marlinspike-NullPrefixWildcardCert-2009-09-29.pem: unknown
>> This Update: Oct 8 21:42:24 2009 GMT
>
> Perhaps even the CRL is issued by the wrong issuer - wouldn't surprise
> me either.
>
Actually I thought you were checking the CRL, not the OCSP responder.
Looking more closely at the command you used, it indeed could indicate
that their OCSP response isn't compliant as I suspected right from the
beginning.
Ian G
> On 10/11/2009 12:25 AM, Ian G:
>>
>> Er.. privacy? traffic monitoring? All yur visits belong to us?
>
> Who says that?
>
> But the "privacy" argument is as brain-dead as the idea itself. Who do
> you want to protect from whom really?
>
> Whoever sniffs a users network already knows where he was heading by
> just looking at the TCP/IP stream. There is no need to try to find out
> by looking at the OCSP request which follows thereafter.
The point is you can sniff a user's network and get one user. Or you
can sniff the CA's network and harvest.
> The CA knows also which site the user wants to visit, it answers the
> very status request. What other privacy issue do you consider worth
> breaking the certificate revocation status?
With privacy, a lot depends on overall attitude. If the CA doesn't care
about privacy and considers cleartext OCSP to be unimportant, chances
are they don't give too hoots for anything else either.
The tech is there to serve the people. Saying you can't do that because
it breaks the tech ... means the tech is broken already.
>> I grant PKI is not understood, but does PKI understand? Is it the
>> mission of PKI to create centralised opportunities of users' browsing
>> habits?
>>
>>
>
> Use CRLs instead of OCSP if you are so inclined, but don't serve either
> CRLs nor OCSP over SSL/TLS please.
>
>> PS: as it happens, CAcert set up is OCSP using HTTPS, because of
>> privacy concerns, *of course*.
>
> That's not surprising really.
>
>> Now there is some discussion going on about removing the recursion in
>> certain browsers, and whether we have to discard the privacy just to
>> get it working.
>
> That's perhaps already a good start with the wrong argument. What privacy?
u-huh. Is this a general feeling within Mozilla?
iang
Eddy Nigg
> On 11/10/2009 06:58, Eddy Nigg wrote:
>>
>> Whoever sniffs a users network already knows where he was heading by
>> just looking at the TCP/IP stream. There is no need to try to find out
>> by looking at the OCSP request which follows thereafter.
>
>
> The point is you can sniff a user's network and get one user. Or you
> can sniff the CA's network and harvest.
Harvest what exactly? That IP xxx.xxx.xxx.xxx requested serial
587439847576398? And what is serial 587439847576398? I mean sniffing on
a specific user's doings makes much more sense. Besides, that would be a
huge load of requests to analyze and parse (depending on the CA), do you
really believe that would remain undetected?
>
> With privacy, a lot depends on overall attitude. If the CA doesn't
> care about privacy and considers cleartext OCSP to be unimportant,
> chances are they don't give too hoots for anything else either.
That's nonsense like all the rest.
>
> The tech is there to serve the people. Saying you can't do that
> because it breaks the tech ... means the tech is broken already.
Considering the concerns you raised - or actually better the concerns
which were raised and you dismissed - I can't see you could bother any
more about a relative minor issue like this one. Besides that it's
pretty invalid in addition to that.
But technology serves you if you know how to apply it. If you are really
concerned about this "privacy" issue, you shouldn't use OCSP, but rely
on CRLs only.
>> That's perhaps already a good start with the wrong argument. What
>> privacy?
>
> u-huh. Is this a general feeling within Mozilla?
>
Again, I fail to see the concern regarding privacy.
Ian G
> On 10/11/2009 12:48 PM, Ian G:
>> On 11/10/2009 06:58, Eddy Nigg wrote:
>>>
>>> Whoever sniffs a users network already knows where he was heading by
>>> just looking at the TCP/IP stream. There is no need to try to find out
>>> by looking at the OCSP request which follows thereafter.
>>
>>
>> The point is you can sniff a user's network and get one user. Or you
>> can sniff the CA's network and harvest.
>
> Harvest what exactly? That IP xxx.xxx.xxx.xxx requested serial
> 587439847576398? And what is serial 587439847576398?
Both of them are tracking numbers, according to privacy doctrine. Certs
have a serial number, and mostly, one cert means one node and/or person.
Same with IP#s. Both have some obfuscations like DHCP, but this
doesn't change the privacy view.
[tech view left out...]
> But technology serves you if you know how to apply it. If you are really
> concerned about this "privacy" issue, you shouldn't use OCSP, but rely
> on CRLs only.
OK, I'll play the game. Do we recomend that when someone clicks on
"privacy mode" on Firefox, it turns off all OCSP?
>>> That's perhaps already a good start with the wrong argument. What
>>> privacy?
>>
>> u-huh. Is this a general feeling within Mozilla?
>>
>
> Again, I fail to see the concern regarding privacy.
If tracking numbers are exported in any sense (two mentioned above) then
we get sucked into a new privacy category. Regulators will assume a
higher category of risk. To use your terms, "don't do that."
Now, clearly, OCSP will have trouble with that. (I wonder what *that*
discussion was like in the PKIX group...)
My point here would be ... watch out for a future bunfight with the
privacy regulators. We already saw a sense of this when the use of
client certificates in Firefox ran into privacy concerns. I forget the
precise bug, but it was to do with the way the "use any cert" button
allowed sites to collect info about the user. Roll on whitelisting...
Does stapling solve this issue?
iang
Eddy Nigg
>
> Both of them are tracking numbers, according to privacy doctrine.
> Certs have a serial number, and mostly, one cert means one node and/or
> person. Same with IP#s. Both have some obfuscations like DHCP, but
> this doesn't change the privacy view.
At the most it means that IP X tried to access a site which had
(probably) the serial number Y, which doesn't even mean that he was
accessing site Z. It might mean a specific site, it might not, because
the certificate might be installed for site W, but the actual site to be
reached was meant to be V or one of the sites listed in the alleged
certificate with number Y allegedly issued by CA A. It's pretty obscure
what it means because nobody sniffing that OCSP responder or user will
know for sure (because the handshake and all interaction happens
otherwise). It's much easier to know which IP address was accessed when
monitoring a user's TCP/IP stream. But even for this, isn't encryption
supposed to protect privacy EVEN you know which connection was
established and to which IP? This is all you can know for sure, OCSP
doesn't increase nor decrease that knowledge significantly.
> OK, I'll play the game. Do we recomend that when someone clicks on
> "privacy mode" on Firefox, it turns off all OCSP?
Certainly not, except in case you turn of SSL/TLS too. And if you do
that, I wonder what privacy mode is supposed to protect (beyond browsing
history and such).
> If tracking numbers are exported in any sense (two mentioned above)
> then we get sucked into a new privacy category. Regulators will
> assume a higher category of risk. To use your terms, "don't do that."
The likelihood that anything can be done with that information if at all
(and this is a very BIG IF) is way smaller than the risk of being MITM'd.
>
> My point here would be ... watch out for a future bunfight with the
> privacy regulators. We already saw a sense of this when the use of
> client certificates in Firefox ran into privacy concerns. I forget
> the precise bug, but it was to do with the way the "use any cert"
> button allowed sites to collect info about the user. Roll on
> whitelisting...
>
Yes, users could be tracked with a silent "give me your cert" request.
However that could be a privacy issue because a user could be tracked
over different sites without his knowledge by somebody he doesn't expect
to share this information. I still fail to see the comparison to an OCSP
request.