Re: Domain-validated name-constrained CA certificates?
On Apr 4, 6:30 pm, Jean-Marc Desperrier wrote: > On 04/04/2010 08:32, Matt McCutchen wrote: > > [...] > > It would be great if a Mozilla-recognized CA would be willing to give > > me, as the registrant of mattmccutchen.net, an intermediate CA > > certificate with a critical name constraint limiting it to > > mattmccutchen.net. > > I don't believe this taking a hammer to crack a nut approach will have > much success. A name-constrained intermediate certificate could be quite convenient for the large organizations that are presently demanding their users to trust private CAs for the whole Web (see bug 501697). Users with new enough NSS would see the sites just work; other users could trust the intermediate certificate as if it were a root. > Especially since there's also the fact the CA would not be > able to constraint the *usage* you give to your certs. An extended key usage of "TLS Web Server Authentication" on the intermediate CA would constrain all sub-certificates, no? -- Matt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Exploitability of the TLS renegotiation prefix-injection attack
On Sun, 2010-04-04 at 14:06 +0300, Eddy Nigg wrote: > On 04/04/2010 01:49 PM, Matt McCutchen: > >> Which is simply another user input (modifiable by the user). > >> > > That's irrelevant. The Referer is an effective XSRF defense because a > > malicious site cannot spoof a Launchpad referrer when sending a request > > to Launchpad. > > > > Huuu? And why not? How would it? What HTML / JavaScript could https://evil.com use to get my browser to issue a malicious request to https://launchpad.net with a referrer of https://launchpad.net ? > Where exactly? I haven't see that this information is not subject to > user modification. You are still missing the point. The user can modify the referrer header, sure, but the attack site that wishes to forge a cross-site request cannot (unless the user specifically modified the browser to allow that, which would be foolish). -- Matt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Domain-validated name-constrained CA certificates?
On 04/04/2010 08:32, Matt McCutchen wrote: [...] It would be great if a Mozilla-recognized CA would be willing to give me, as the registrant of mattmccutchen.net, an intermediate CA certificate with a critical name constraint limiting it to mattmccutchen.net. I don't believe this taking a hammer to crack a nut approach will have much success. Especially since there's also the fact the CA would not be able to constraint the *usage* you give to your certs. #2. The tooltip of the Firefox SSL badge (a.k.a. "Larry" site identity button) shows the Organization field of the lowest CA certificate, [...] The registrant could put a misleading value in this field. [...] Should Firefox show the organization name of the root CA instead, since it is ultimately responsible for all validation paths that end at its trust bit? We are to something much more interesting here. I'm not sure it's really a great practice to have only one level that's taken into account there. But then only the root might be a bit too much in the other side. So, maybe something better is needed but it's not easy to decide what. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Exploitability of the TLS renegotiation prefix-injection attack
On 04/04/2010 01:49 PM, Matt McCutchen: Which is simply another user input (modifiable by the user). That's irrelevant. The Referer is an effective XSRF defense because a malicious site cannot spoof a Launchpad referrer when sending a request to Launchpad. Huuu? And why not? See this article, section 4.2, conclusion #1: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.140.2584&rep=rep1&type=pdf Where exactly? I haven't see that this information is not subject to user modification. -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Exploitability of the TLS renegotiation prefix-injection attack
On Sun, 2010-04-04 at 13:07 +0300, Eddy Nigg wrote: > On 04/04/2010 07:44 AM, Matt McCutchen: > > Such configurations are uncommon, but they are not intrinsically > > unreasonable. Sites that put parameters in URI path components are > > likely to keep the same approach for their write requests. For example, > > but for Launchpad's refusal of client-initiated renegotiation, it would > > be vulnerable to a request to subscribe to one bug being changed to a > > different bug. (Note that they use the Referer, not a token for XSRF > > protection.) > > > > Which is simply another user input (modifiable by the user). That's irrelevant. The Referer is an effective XSRF defense because a malicious site cannot spoof a Launchpad referrer when sending a request to Launchpad. See this article, section 4.2, conclusion #1: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.140.2584&rep=rep1&type=pdf -- Matt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Alerts on TLS Renegotiation
On 04/04/2010 09:34 AM, Nelson B Bolyard: It's not so trivial. It's trivial from the logical point of view. I did wonder about this once or twice over 13 years, but didn't see any way to exploit it and so I thought it was safe. Someone finally found a way. Thank goodness Marsh Ray wears a white hat! Unfortunately we don't know how many times this has been used successfully. Thanks for the explanations, it broadened my understanding about its potential misuse. -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Different services on the same server - RFC 4985
On 04/04/2010 01:37 PM, Matt McCutchen: This might interest you: http://tools.ietf.org/html/draft-saintandre-tls-server-id-check-02 You're right that it interests me, but I don't see where it addresses name constraints or distinguishing among services. That's just the next steps to include it in the certificates. Peter has been working with us for the XMPP certificates, but unfortunately we haven't come about to actually do that. It's still on my plate though... -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Different services on the same server - RFC 4985
On Sun, 2010-04-04 at 03:19 -0400, Matt McCutchen wrote: > The real problem there is that TLS uses DNS names and thus does not > distinguish different services on the same server. Using RFC 4985 > SRVNames such as _SMTP.example.com in certificates would solve that. I meant to add: Server Name Indication should use SRVNames too. That way, an attempt to connect a client to the wrong service can be caught at the TLS level even if the same certificate is used, since the server_name extension is integrity-protected by the Finished hash. -- Matt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Different services on the same server - RFC 4985
On Sun, 2010-04-04 at 13:31 +0300, Eddy Nigg wrote: > On 04/04/2010 10:19 AM, Matt McCutchen: > > - RFC 4985 section 4 should be clearer that dNSName constraints as such > > apply to SRVNames and the SRVName type is only used for constraints that > > contain a service name. I may raise that on the pkix list. > > > > This might interest you: > http://tools.ietf.org/html/draft-saintandre-tls-server-id-check-02 You're right that it interests me, but I don't see where it addresses name constraints or distinguishing among services. -- Matt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Different services on the same server - RFC 4985
On 04/04/2010 10:19 AM, Matt McCutchen: - RFC 4985 section 4 should be clearer that dNSName constraints as such apply to SRVNames and the SRVName type is only used for constraints that contain a service name. I may raise that on the pkix list. This might interest you: http://tools.ietf.org/html/draft-saintandre-tls-server-id-check-02 -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Exploitability of the TLS renegotiation prefix-injection attack
On 04/04/2010 07:44 AM, Matt McCutchen: Such configurations are uncommon, but they are not intrinsically unreasonable. Sites that put parameters in URI path components are likely to keep the same approach for their write requests. For example, but for Launchpad's refusal of client-initiated renegotiation, it would be vulnerable to a request to subscribe to one bug being changed to a different bug. (Note that they use the Referer, not a token for XSRF protection.) Which is simply another user input (modifiable by the user). I'll admit this is not a very serious compromise, but it illustrates the point. It's totally unfair to expect web developers to have anticipated that this configuration might be a bad idea. Well, those are not only bad ideas, they are most likely vulnerable to all kinds of other attacks. The renegotiation flaw is just another contributing fact which obviously shouldn't happen, but even without it it's certainly no guaranty for protection for this kind of coding. -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Different services on the same server - RFC 4985
On Sat, 2010-04-03 at 23:34 -0700, Nelson B Bolyard wrote: > Let me tell you about one very simple attack. (I think this is old enough > now that the details are no longer big news in the hacking community.) The > MITM has an account on an SMTP server on the same host as an https server. > The SMTP server and the https server on that host use the same server > certificate. The attacker arranges to intercept the victim client's https > requests and connect them to the email server (!). The real problem there is that TLS uses DNS names and thus does not distinguish different services on the same server. Using RFC 4985 SRVNames such as _SMTP.example.com in certificates would solve that. Two issues: - Astonishingly, a service name for HTTP has not yet been registered with IANA ( http://www.iana.org/assignments/service-names ). Somebody should do that! - RFC 4985 section 4 should be clearer that dNSName constraints as such apply to SRVNames and the SRVName type is only used for constraints that contain a service name. I may raise that on the pkix list. -- Matt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
