Mailing List Archive

SSL: how to tell client what certificate to expect?
I don't quite understand Conserver's SSL support. What is the purpose
of specifying a certificate for a client, if the server cannot use it to
identify a particular user?

How do I tell the client what certificate to expect (or what CA to expect
to have signed it) for the server? If there's no way to do that, then
there is no real protection from using SSL, since it is trivial to conduct
a man-in-the-middle attack using any certificate that one happens to have
handy...

--
Thor Lancelot Simon
Coyote Point Systems, Inc. <tls@coyotepoint.com>
Millerton, NY, USA
_______________________________________________
users mailing list
users@conserver.com
https://www.conserver.com/mailman/listinfo/users
Re: SSL: how to tell client what certificate to expect? [ In reply to ]
On Mon, Nov 01, 2010 at 06:19:28PM -0400, Thor Simon wrote:
> I don't quite understand Conserver's SSL support. What is the purpose
> of specifying a certificate for a client, if the server cannot use it to
> identify a particular user?

Well, if you provide the certificate, it needs to succeed it's
authenticity check. If you don't provide one at all, it falls back to
an anonymous cipher (so, it's encrypted, but not authenticated and
subject to man-in-the-middle).

> How do I tell the client what certificate to expect (or what CA to expect
> to have signed it) for the server? If there's no way to do that, then
> there is no real protection from using SSL, since it is trivial to conduct
> a man-in-the-middle attack using any certificate that one happens to have
> handy...

There's no hook for specifying a different CA or CA repository. It uses
whatever openssl was built with...and if you have the CA in your global
repository, it should succeed and be fine. If you don't it should fail
with a validation error.

So, to "summarize":

- No certificates on client or server
- anonymous ciphers are used and you get encryption without
authentication

- Server-side certificate only
- client must validate certificate with global openssl CA store
- server doesn't require or receive a client certificate, and is fine
with that

- Client-side certificate only
- server must validate certificate with global openssl CA store
- client doesn't require or receive a server certificate, and is fine
with that

- Server-side and client-side certificate
- client must validate certificate with global openssl CA store
- server must validate certificate with global openssl CA store

Adding a hook to require the client certificate is the potentially
missing piece - so you can force clients to provide a certificate.
Adding a hook to override the CA store would possibly be useful as well.

I *think* if you modify conserver/main.c and replace "SSL_VERIFY_PEER"
with "SSL_VERIFY_PEER|SSL_VERIFY_FAIL_IF_NO_PEER_CERT" you get the
client certificate enforcement. It needs to be tested and a
configuration hook provided if so. But perhaps it's enough for you to
get the config you'd like right now.

Bryan
_______________________________________________
users mailing list
users@conserver.com
https://www.conserver.com/mailman/listinfo/users
Re: SSL: how to tell client what certificate to expect? [ In reply to ]
On Mon, Nov 01, 2010 at 11:41:26PM +0000, Bryan Stansell wrote:
>
> Well, if you provide the certificate, it needs to succeed it's
> authenticity check. If you don't provide one at all, it falls back to
> an anonymous cipher (so, it's encrypted, but not authenticated and
> subject to man-in-the-middle).

But anyone can man-in-the-middle the client by pretending to be a server
with no certificate, no?

Thor
_______________________________________________
users mailing list
users@conserver.com
https://www.conserver.com/mailman/listinfo/users
Re: SSL: how to tell client what certificate to expect? [ In reply to ]
On Mon, Nov 01, 2010 at 09:25:41PM -0400, Thor Simon wrote:
> On Mon, Nov 01, 2010 at 11:41:26PM +0000, Bryan Stansell wrote:
> >
> > Well, if you provide the certificate, it needs to succeed it's
> > authenticity check. If you don't provide one at all, it falls back to
> > an anonymous cipher (so, it's encrypted, but not authenticated and
> > subject to man-in-the-middle).
>
> But anyone can man-in-the-middle the client by pretending to be a server
> with no certificate, no?
>
> Thor

Isn't that what I said? ;-)

But, taking that a step further, my summary before was off. In the case
where the client has a certificate and the server doesn't, it's really:

- Client-side certificate only
- server fails SSL handshake
- *this just won't work*

The reason? We disable anonymous ciphers if we load a certificate. I
haven't looked into the exact reasons (dunno the low-level details of
the SSL protocol - at least not as much as before) but a test showed it
fails the handshake. Now, if the server ignores this issue, perhaps it
can fake it out. I assume the client side would fail handshake as well
if the server didn't provide a cert (since it won't accept anonymous
ciphers). Maybe someone out there knows the protocol. Otherwise, it'll
require some testing - but this is my best guess right now. So, I
*think* it's safe to say you're talking to the right server as long as
you have a certificate loaded and the proper CA repository on the client.

I do agree that more hooks to force this would be nice (like, you *must*
validate with this CA or whatever).

Bryan
_______________________________________________
users mailing list
users@conserver.com
https://www.conserver.com/mailman/listinfo/users
Re: SSL: how to tell client what certificate to expect? [ In reply to ]
On Tue, Nov 02, 2010 at 02:41:40AM +0000, Bryan Stansell wrote:
> On Mon, Nov 01, 2010 at 09:25:41PM -0400, Thor Simon wrote:
> > On Mon, Nov 01, 2010 at 11:41:26PM +0000, Bryan Stansell wrote:
> > >
> > > Well, if you provide the certificate, it needs to succeed it's
> > > authenticity check. If you don't provide one at all, it falls back to
> > > an anonymous cipher (so, it's encrypted, but not authenticated and
> > > subject to man-in-the-middle).
> >
> > But anyone can man-in-the-middle the client by pretending to be a server
> > with no certificate, no?
>
> Isn't that what I said? ;-)

Well, not exactly. I can provide a certificate on the server side and
still be subject to a man-in-the-middle attack by an adversary who has
no certificate at all! That's not how I read what you wrote before, at
least.

Thor
_______________________________________________
users mailing list
users@conserver.com
https://www.conserver.com/mailman/listinfo/users