Re: [TLS] [pkix] New version of Multiple OCSP mode of Certificate

[Martin Rex <[e-mail]>]

Yngve N. Pettersen wrote:
> 
> On Wed, 04 Aug 2010 22:39:08 +0200, Martin Rex <[e-mail]> wrote:
> 
> > Marsh Ray wrote:
> >>
> >> For example, is this outbound connection willing to authenticate with
> >> the credentials of the user? Nearly every form of user credentials have
> >> turned out to be forwardable in one way or another.
> >
> > Possible problems;+
> >
> > That crafted AIA-request could potentially "leak" information,
> > including sensitive information through a protocol of the attackers
> > choice to a target of the attackers choice (cookies, other
> > http-header-field contents, http-refererrers, basic authentication
> > credentials).
> 
> Opera's AIA/OCSP/CRL requests are sent with cookies, referrers, etc.  
> disabled; and additionally anything which would cause a user-interaction  
> will immediately cause the request to fail.

I'm slightly more concerned about what MSIE will do, because that
is still a pretty common browser supplied to IT departments...

The issue is, that it is so easy to get it wrong, that some implementations
are going to get it wrong.  If commercial CAs issue X.509v3 CA(!) certs
without Basic Constraints and KeyUsage, and none of the browser vendors
complains about this, but instead ship it as pretrusted, then I have
little hope about this one.

> 
> > That crafted AIA-request could be accessing resources that are not
> > accessible to the attacker himself with a protocol of the attackers  
> > choice
> > and result in reaction that help the attacker in carrying out a more
> > complex attack (like opening ports on a NAT-style firewall).
> 
> Opera have policies in place that prevent many kinds of cross  
> network-category attacks, including that one.

Huh?  How?

The idea to check digital signatures only with trusted keying material
is that an attacker can not entice you to verify digital signatures
with megabit-sized keys that aren't trusted anyway.  While I could
think of effective plausibility checks for key sizes, it is currently
unclear to me how you limit to which hosts AIA could connect.
An attacker could certainly add an IP-address of your internal
network to a DNS zone under his control, and what about HTTP redirects?


>
> As for AIA itself, I will note that it is documented in RFC 5280, sec.  
> 4.2.2.1 for precisely the purpose it is being used for by Opera
> 
>     In a public key certificate, the id-ad-caIssuers OID is used when the
>     additional information lists certificates that were issued to the CA
>     that issued the certificate containing this extension.  The
>     referenced CA issuers description is intended to aid certificate
>     users in the selection of a certification path that terminates at a
>     point trusted by the certificate user.

Well, at least rfc-5280 includes the conscious user firmly within
the loop of "aid certificate users in the seledtion of a certification
path".

The concern that I've been voicing is AIA-retrieval without involving
the conscious decision of a user to access a arbitrary resource from
a completely untrusted potential attacker.


> 
> The kind of crafted URLs you are concerned about can also be injected by  
> way of OCSP and CRL URLs, and OCSP is AFAICT actually supported by more  
> clients than AIA CA.

That is incorrect.  The path validation algorithm checks cryptographic
correctness and certificate (attribute) validity starting at a trust
anchor first, and ONLY when that succeeds, CRLs and OCSP is checked.
So when doing path validation correctly, you never access untrusted
CRL and OCSP resources.


> 
> Also, injecting those URLs also indicate either the ability to trick the  
> user into visiting the malicious site, or the attacker already have  
> complete control over the user's unencrypted connection, in which case  
> there are far easier ways to inject such URLs for most purposes.

A user that only ever used HTTPS to access only sites that he trusts
was originally protected from attackers capable of blindly injecting
a ServerHello+ServerCertificate data into the receiving side of 
a new TCP to someone elses Web Server on port 443.
(or any other outgoing protocol involving SSL/TLS for
generic TLS implementations other than browsers with AIA-retrieval).

The use of SSL should make users of that technology _more_ secure,
and avoid "adding value" of the kind of an significant additional
attack surface to the software and environment of the user.


Concerning sensible client behaviour:
3 years ago I received an S/Mime signed EMail confirming the order
of a replacement keycard for my (company car) from the maintenance
contractor.  There were two certs included in the S/Mime signature
(signature cert of contractors employee and cert of an intermediateCA),
but the Root CA (CN=RootCA <Car-Manufacturer>, O=<car-manufacturer>"
was missing and is not publicly available (I still don't have it today).
While MS CryptoAPI might be capable and willing to perform extremely
dangerous things as secretly accessing arbitrary attacker-supplied
AIA-cert-locations, I find myself completely unable (w2k3) to mark that
intermediateCA cert as trusted and get the signature verified.
(the option to select the signer cert as trusted is greyed out, which
 might be a group/domain policy issue either based on dumb defaults
 or deliberate choice of an uninformed admin).


So by leaving it up to implementors to come up with sensible
implementation choices for security-relevant characteristics,
you may easily end up with something that's both insecure and
usability-impaired...


-Martin