[go: up one dir, main page]

|
|
Log in / Subscribe / Register

A crypto library aimed at auditability

A crypto library aimed at auditability

Posted Jan 13, 2014 19:39 UTC (Mon) by luto (subscriber, #39314)
In reply to: A crypto library aimed at auditability by dlang
Parent article: A crypto library aimed at auditability

Once you're talking about asking for a client certificate mid-connection, though, the application layer very much needs to know about it -- it has to know to ask for the certificate.


to post comments

A crypto library aimed at auditability

Posted Jan 13, 2014 20:02 UTC (Mon) by dlang (guest, #313) [Link] (8 responses)

> Once you're talking about asking for a client certificate mid-connection, though, the application layer very much needs to know about it -- it has to know to ask for the certificate.

What happens with Apache is that you configure a directory to require a client cert. When someone tries to access that directory, the authentication check fails and triggers a renegotiation.

Yes, you could redirect them to a different domain, but that would require a different cert (and IP address with SSL), this may not be a big deal for a single site, but at my last job we have a couple thousand such sites, at that point doubling the number of certs and IP addresses needed is a big deal.

A crypto library aimed at auditability

Posted Jan 13, 2014 20:03 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

> Yes, you could redirect them to a different domain, but that would require a different cert (and IP address with SSL), this may not be a big deal for a single site, but at my last job we have a couple thousand such sites, at that point doubling the number of certs and IP addresses needed is a big deal.

Let me chime in and say that this is YET ANOTHER case of mixing network layers. SSL/TLS are just designed too badly.

A crypto library aimed at auditability

Posted Jan 13, 2014 20:06 UTC (Mon) by luto (subscriber, #39314) [Link]

I'm not sure that we're talking about the same thing. All I'm saying is that, for an application (e.g. Apache) to ask for a certificate mid-connection (e.g. when it sees GET /super_secret), it needs to know about the underlying crypto layer (so it can ask for that certificate).

It's true that, in TLS, this can be done without modifying HTTP, but I'm not sure that's a good thing. In any case, a different crypto layer could support the operation "ask for a client certificate" without renegotiating any session keys.

A crypto library aimed at auditability

Posted Jan 13, 2014 21:19 UTC (Mon) by mathstuf (subscriber, #69389) [Link] (5 responses)

> and IP address with SSL

Maybe come April you could just start assuming SNI ;) .

A crypto library aimed at auditability

Posted Jan 13, 2014 21:32 UTC (Mon) by dlang (guest, #313) [Link] (4 responses)

that depends on if you need to support older browsers or not. That's a business decision, not a technical one.

A crypto library aimed at auditability

Posted Jan 13, 2014 22:56 UTC (Mon) by mathstuf (subscriber, #69389) [Link] (3 responses)

It is a business decision, but its the SSL implementation in XP that doesn't support SNI, not the browser itself and it doesn't look like browsers can do much (I see reports of Chrome 24 not supporting SNI on XP).

A crypto library aimed at auditability

Posted Jan 16, 2014 9:30 UTC (Thu) by ssokolow (guest, #94568) [Link] (2 responses)

Browsers on XP will have TLS SNI if they bring along their own crypto libraries rather than using the OS-provided ones. (Which everyone except IE and Safari for Windows does apparently)

According to Wikipedia, Chrome uses Firefox's NSS libraries and SHOULD have working TLS SNI under XP but it's broken somehow.

A crypto library aimed at auditability

Posted Jan 16, 2014 13:52 UTC (Thu) by cortana (subscriber, #24596) [Link] (1 responses)

Chrome uses the Windows API for SSL on Windows.

A crypto library aimed at auditability

Posted Jan 16, 2014 13:57 UTC (Thu) by mathstuf (subscriber, #69389) [Link]

It looks like there is also a registry value[1], but it defaults to 0. That's for crome-frame, not Chrome itself, but I imagine Chrome would have its own stack if chrome-frame does.

I also saw that Firefox 3 worked on XP, so it does look like it *can work there.

[1]https://groups.google.com/forum/m/#!topic/google-chrome-f...


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds