Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Getting SSL certificate

5 views
Skip to first unread message

Stuart D. Gathman

unread,
Nov 7, 2002, 10:31:18 PM11/7/02
to
The httplib modules supports SSL, but does not check certificates. Fine,
but I couldn't find a way to get the server certificate to check it
myself. How do I get the server certificate from an HTTPSConnection
object? I dug down to where it calls the _socket C module, and still
didn't find anything that would fetch this info for me.

For this application, I just need to check for a specific name and
specific signer. I suppose checking that the signature is valid could get
involved, but I can't try until I can get the certificate. And attempting
to check with false positives is no worse than not checking at all.

Furthermore, when playing with urllib, proxies don't seem to work with the
https protocol. It passes the "https://host.com" url to the proxy server,
instead of using the proxy CONNECT request needed for SSL. Am I doing
something wrong? I set the proxy like this:

export https_proxy="http://myproxyhost:8081"

(And http_proxy works as expected.)

--
Stuart D. Gathman <stu...@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flamis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

Martin v. Loewis

unread,
Nov 8, 2002, 2:17:03 AM11/8/02
to
"Stuart D. Gathman" <stu...@bmsi.com> writes:

> The httplib modules supports SSL, but does not check certificates.

It would, if you would pass key_file and cert_file arguments to
HTTPSConnection. Atleast theoretically; I doubt this has been tested
much.

> Furthermore, when playing with urllib, proxies don't seem to work with the
> https protocol. It passes the "https://host.com" url to the proxy server,
> instead of using the proxy CONNECT request needed for SSL. Am I doing
> something wrong?

Can you please explain what the CONNECT request is? I have never heard
of it.

Regards,
Martin

Erno Kuusela

unread,
Nov 8, 2002, 3:16:37 AM11/8/02
to
In article <m3smycj...@mira.informatik.hu-berlin.de>,

mar...@v.loewis.de (Martin v. Loewis) writes:

| "Stuart D. Gathman" <stu...@bmsi.com> writes:
|| The httplib modules supports SSL, but does not check certificates.

| It would, if you would pass key_file and cert_file arguments to
| HTTPSConnection. Atleast theoretically; I doubt this has been tested
| much.

what do these arguments do? i had been under the impression
that key_file is for sending a client certificate, and cert_file
was for a certificate authority that the server cert should be
checked against. but it is a faint impression :)

in case it is so, this still does not let you at the server
certificate...

-- erno

Martin v. Löwis

unread,
Nov 8, 2002, 7:01:01 AM11/8/02
to
Erno Kuusela <erno...@erno.iki.fi> writes:

> || The httplib modules supports SSL, but does not check certificates.

Can you please explain what it means to check a certificate?

> what do these arguments do? i had been under the impression
> that key_file is for sending a client certificate,

Correct, so probably not relevant.

> and cert_file was for a certificate authority that the server cert
> should be checked against. but it is a faint impression :)

Yes. And you need such a thing to check a server certificate.

> in case it is so, this still does not let you at the server
> certificate...

Is there a missing here?

Regards,
Martin

Stuart D. Gathman

unread,
Nov 8, 2002, 10:55:23 PM11/8/02
to
On Fri, 08 Nov 2002 07:01:01 -0500, Martin v. Löwis wrote:

> Erno Kuusela <erno...@erno.iki.fi> writes:
>
>> || The httplib modules supports SSL, but does not check certificates.
>
> Can you please explain what it means to check a certificate?

I know of two level of checking:

1) an automatic level that verifies all digital signatures on the cert
this tells you that someone registered the cert with the CA, and it
has not been forged (presumably the SSL protocol signs some random data
unique to the session along with the cert to prevent replay).

2) a manual level where a person or high level program checks that the
name on the certificate is one they expect, or feel like trusting.

In my case, there is only one cert that the application will trust - but
I need to make sure it hasn't been forged.

>> and cert_file was for a certificate authority that the server cert
>> should be checked against. but it is a faint impression :)

That would make sense, but the docs say that checking the server certificate
is not implemented.

>> in case it is so, this still does not let you at the server
>> certificate...

> Is there a missing here?

Definitely, because even if the checking for level (1) above were
automatic (as the arguments seem intended for), the application still
needs to get at the server certificate in some form to check that they
are talking to the right entity. Anybody and their dog can get a signed
certificate. (And I remember a Slashdot story about someone getting a
certificate for their dog to illustrate how weak the checking at Verisign
is.)

Martin v. Loewis

unread,
Nov 9, 2002, 1:56:59 AM11/9/02
to
"Stuart D. Gathman" <stu...@bmsi.com> writes:

> In my case, there is only one cert that the application will trust - but
> I need to make sure it hasn't been forged.

I think this is done by passing the certfile argument.

> >> and cert_file was for a certificate authority that the server cert
> >> should be checked against. but it is a faint impression :)
>
> That would make sense, but the docs say that checking the server certificate
> is not implemented.

Did you try? Python passes the cert_file argument to
SSL_CTX_use_certificate_chain_file. It might be a problem that Python
never calls SSL_get_verify_result, though (but then, I understand that
the default verify callback will return preverify_ok, so if the server
certificate could not be verified, the TLS handshake will be
terminated).

> Definitely, because even if the checking for level (1) above were
> automatic (as the arguments seem intended for), the application still
> needs to get at the server certificate in some form to check that they
> are talking to the right entity. Anybody and their dog can get a signed
> certificate.

No. Not from the CA in the chain you are passing.

In any case, if you get to the SSL object, invoking .server() and
.issuer() on it will tell you the identity of the server (after the
connection has been established). That, of course, can only complement
the check that the certificate has not been forged; you really need to
pass a certificate chain for validation.

Regards,
Martin

Stuart D. Gathman

unread,
Nov 9, 2002, 11:27:24 PM11/9/02
to
On Sat, 09 Nov 2002 01:56:59 -0500, Martin v. Loewis wrote:

>> That would make sense, but the docs say that checking the server
>> certificate is not implemented.
>
> Did you try? Python passes the cert_file argument to
> SSL_CTX_use_certificate_chain_file. It might be a problem that Python
> never calls SSL_get_verify_result, though (but then, I understand that
> the default verify callback will return preverify_ok, so if the server
> certificate could not be verified, the TLS handshake will be
> terminated).

Tying doesn't tell me whether the cert was actually checked. I don't get
any errors, however, poking around in the C source for socketmodule.c, I
find for opening an SSL connection:

if (key_file) {
if (SSL_CTX_use_PrivateKey_file(self->ctx, key_file,
SSL_FILETYPE_PEM) < 1) {
errstr = "SSL_CTX_use_PrivateKey_file error";
goto fail;
}

if (SSL_CTX_use_certificate_chain_file(self->ctx,
cert_file) < 1) {
errstr = "SSL_CTX_use_certificate_chain_file error";
goto fail;
}
}

SSL_CTX_set_verify(self->ctx,
SSL_VERIFY_NONE, NULL); /* set verify lvl */
self->ssl = SSL_new(self->ctx); /* New ssl struct */
SSL_set_fd(self->ssl, Sock->sock_fd); /* Set the socket for SSL */
SSL_set_connect_state(self->ssl);
/* Actually negotiate SSL connection */
/* XXX If SSL_connect() returns 0, it's also a failure. */
ret = SSL_connect(self->ssl);

And the openssl docs have this to say about SSL_VERIFY_NONE:

SSL_VERIFY_NONE
Server mode: the server will not send a client
certificate request to the client, so the client will
not send a certificate.

Client mode: if not using an anonymous cipher (by
default disabled), the server will send a certificate
which will be checked. The result of the certificate
verification process can be checked after the TLS/SSL
handshake using the SSL_get_verify_result(3) function.
The handshake will be continued regardless of the
verification result.

socketmodule.c never calls SSL_get_verify_result()

It seems that the docs are correct. The certificate is not validated and
I could be talking to anybody or their dog. Furthermore, while the
server and issuer are exposed through undocumented attributes, the
server_cert is not. So there is no way to validate the cert manually,
short of rewriting socketmodule.c. This is one case where the batteries
included have been sitting on the shelf too long.

If only the server_cert were available, validating it is not too much
work. There is an external 'verify' program supplied with openssl that
does most of the work for you.

Martin v. Loewis

unread,
Nov 10, 2002, 2:49:52 AM11/10/02
to
"Stuart D. Gathman" <stu...@bmsi.com> writes:

> Tying doesn't tell me whether the cert was actually checked.

It does if you produce a case which should fail, e.g. by providing a
CA chain which the server won't verify against.

> socketmodule.c never calls SSL_get_verify_result()

So this could be fixed by exposing SSL_get_verify_result, right?

> It seems that the docs are correct. The certificate is not validated and
> I could be talking to anybody or their dog. Furthermore, while the
> server and issuer are exposed through undocumented attributes, the
> server_cert is not. So there is no way to validate the cert manually,
> short of rewriting socketmodule.c. This is one case where the batteries
> included have been sitting on the shelf too long.

Definitely. It's a chicken-and-egg problem: Nobody believes the
builtin SSL support is useful, so nobody contributes
improvements. That is very unfortunate.

> If only the server_cert were available, validating it is not too much
> work. There is an external 'verify' program supplied with openssl that
> does most of the work for you.

While that might be the case, I don't really see the need for that. If
you expose SSL_get_verify_result, your application would work, right?

If you provide a patch that exposes both (get_verify_result, and
server_cert), this would be most appreciated.

Regards,
Martin

Erno Kuusela

unread,
Nov 10, 2002, 3:09:11 PM11/10/02
to
In article <j48z04z...@informatik.hu-berlin.de>,
loe...@informatik.hu-berlin.de (Martin v. Löwis) writes:

| Erno Kuusela <erno...@erno.iki.fi> writes:
|| in case it is so, this still does not let you at the server
|| certificate...

| Is there a missing here?

sorry, i had read the original question badly and did not notice he
ultimately wanted to verify it as per usual.

-- erno

Stuart D. Gathman

unread,
Nov 10, 2002, 9:32:06 PM11/10/02
to
On Sun, 10 Nov 2002 02:49:52 -0500, Martin v. Loewis wrote:

> While that might be the case, I don't really see the need for that. If
> you expose SSL_get_verify_result, your application would work, right?
>
> If you provide a patch that exposes both (get_verify_result, and
> server_cert), this would be most appreciated.

You are correct. I have to provide a proof of concept demo by the 15th -
so I will go ahead and use python, glossing over the lack of actual
certificate verification for the demo. I am confident now that I can
patch socketmodule.c to provide the needed functionality later. This is
for a business EDI application, and the PHB believes that it must already
be secure because it uses SSL - so the lack of authentication won't be
noticed for the demo. He simply does not understand how you could be
talking to the wrong party if it's encrypted.

0 new messages