EldoS | Feel safer!

Software components for data protection, secure storage and transfer

HTTPS connection: I'm confused

Also by EldoS: CallbackFilter
A component to monitor and control disk activity, track file and directory operations (create, read, write, rename etc.), alter file data, encrypt files, create virtual files.
#773
Posted: 07/20/2006 02:44:46
by Stephane Grobety (Priority Standard support level)
Joined: 04/18/2006
Posts: 170

Hello,

I got a little problem: I'm trying to establish an HTTPS connection to a remote site. I'm required to use a client certificate for my end of the connection (I got one) and verify the other web site's identity.

It's a bit complex because I don't have access to the "live" site yet. However, I've tryied to run tests on several other HTTPS servers and I came up with very strange results.

First, I tried to connect without even attempting to verify anything in the certificate or use a local one. I discovered that the TElHTTPSClient component doesn't properly handle DATE headers that aren't in the GMT toime zone: as soon as the time zone section differs from "GMT", it reverts to the client's current date and time.

But the main problem is that I simply do not understand how I am supposed to read and parse the certificates I'm given during the handling. I'm receiving several certificates in turn and I assume that is the certificate chain. However, I can't verify them at all because of the way the component passes them to me: I receive them in the OnCertificateValidate even handler I wrote and I'm supposed to say whether or not they are valid.

The truth is: I have no way to KNOW if they are valid before I received the whole chain and I have no way to know whether I've received it or not.

Additionally, the actual application will require to check for a specific certificate: not any certificate issued by a known authority but one that was transmitted through a different channel (although it will probably be signed by a CA). Now, how can I verify if a certificate is "valid" without verifying the whole chain ? Is it even possible ? How can I assert that two certificates are identical ? do I have to compare them byte by byte ?

Thanks
#774
Posted: 07/20/2006 03:02:39
by Eugene Mayevski (EldoS Corp.)

Quote
Stephane Grobety wrote:
First, I tried to connect without even attempting to verify anything in the certificate or use a local one. I discovered that the TElHTTPSClient component doesn't properly handle DATE headers that aren't in the GMT toime zone: as soon as the time zone section differs from "GMT", it reverts to the client's current date and time.


Can you please direct me at some public server which gives the date with GMT+Offset?

Quote
Stephane Grobety wrote:
But the main problem is that I simply do not understand how I am supposed to read and parse the certificates I'm given during the handling. I'm receiving several certificates in turn and I assume that is the certificate chain. However, I can't verify them at all because of the way the component passes them to me: I receive them in the OnCertificateValidate even handler I wrote and I'm supposed to say whether or not they are valid.

The truth is: I have no way to KNOW if they are valid before I received the whole chain and I have no way to know whether I've received it or not.


This is the way SSL works :(

What you can do is oneo of the following:

scenario 1:

collect all certificates to MemoryCertStorage and set Valid to true. Validate the certificates in response to OnOpenConnection event and close the connection if the certificates are not valid.

scenario 2: collect all certificates to MemoryCertStorage and set Valid to true until you receive the certificate that is issued for the site you are connecting to (end-entity cert). When you receive this certificate, validate the whole certificate chain.
In OnOpenConnection event handler check if you ever received end-entity certificate. If you didn't, then close connection.

Quote
Stephane Grobety wrote:
Additionally, the actual application will require to check for a specific certificate: not any certificate issued by a known authority but one that was transmitted through a different channel (although it will probably be signed by a CA). Now, how can I verify if a certificate is "valid" without verifying the whole chain ? Is it even possible ? How can I assert that two certificates are identical ? do I have to compare them byte by byte ?


As you like. Comparing them is also a valid way, but it is possible that you will also need to check whether the certificate is revoked by either downloading a CRL (if you can get the CRL's URL either from the CA certificate or from third-party) or using OCSP client.


Sincerely yours
Eugene Mayevski
#775
Posted: 07/20/2006 03:15:26
by Stephane Grobety (Priority Standard support level)
Joined: 04/18/2006
Posts: 170

Thanks for the quick answer :)

Quote
Can you please direct me at some public server which gives the date with GMT+Offset?


https://mail.fulgan.com/

The client component has a problem with that server ATM but I'm not sure it isn't something I did wrong. Yet, you'll receive the HTTP response header with a date field set in UTC+2

Quote

scenario 2: collect all certificates to MemoryCertStorage and set Valid to true until you receive the certificate that is issued for the site you are connecting to (end-entity cert). When you receive this certificate, validate the whole certificate chain.
In OnOpenConnection event handler check if you ever received end-entity certificate. If you didn't, then close connection.


How do I know that the certificate I receive IS the end-entity cert ? Is there a flag to that effect or do I have to compare the CN with the host name ? Or do I have to build the certificate chain "by hand" ?

Quote

As you like. Comparing them is also a valid way, but it is possible that you will also need to check whether the certificate is revoked by either downloading a CRL (if you can get the CRL's URL either from the CA certificate or from third-party) or using OCSP client.


Hm. Ok. Please excuse me if that question sounds silly but: how can I prevent a MIM attack in that scenario ? Does SBB make sure that the public key linked to the certificate is indeed the one used to establish the session key ? Do I have to validate all the certificates anyway ?

Thank you again
#776
Posted: 07/20/2006 03:20:34
by Stephane Grobety (Priority Standard support level)
Joined: 04/18/2006
Posts: 170

One more thing: I can't find any "OnOpenConnection" event in the client component.
#778
Posted: 07/20/2006 04:11:52
by Eugene Mayevski (EldoS Corp.)

Quote
Stephane Grobety wrote:
Is there a flag to that effect or do I have to compare the CN with the host name ?


Yes, you need to compare host name to certificate data.
Quote
Stephane Grobety wrote:
Or do I have to build the certificate chain "by hand" ?


The chain is built by CertificateStorage (see CertChains property in TElCustomCertStorage).

Quote
Stephane Grobety wrote:
Does SBB make sure that the public key linked to the certificate is indeed the one used to establish the session key ? Do I have to validate all the certificates anyway ?


You need to validate all certificates AND compare the end-entity one with the cert. you stored in your application.

Quote
Stephane Grobety wrote:
One more thing: I can't find any "OnOpenConnection" event in the client component.


Good point. Use OnReceivingHeaders then. We'll add OnOpenConnection to SecureBlackbox 5.


Sincerely yours
Eugene Mayevski
#779
Posted: 07/20/2006 04:29:06
by Stephane Grobety (Priority Standard support level)
Joined: 04/18/2006
Posts: 170

Quote
Yes, you need to compare host name to certificate data.


Hm. Supposing the host name doesn't match anything in the chain, how would I know which certificate is intended to be the end entity ? I suppose that I would need to read the store's "Chains" property and hope there is only one of them, right ?

Quote
You need to validate all certificates AND compare the end-entity one with the cert. you stored in your application.


Aw... That's anoying... I'm not using any of the system stores to validate these certificate so that means I'll have to build my own trusted roots store.

Well, if that can't be helped, that can't be helped, I gather.

Quote
Use OnReceivingHeaders then. We'll add OnOpenConnection to SecureBlackbox 5.


Thanks.

If I can make a suggestion, it could be helpful to add to the documentation a map of all the events that are firedt, in what order and what the session state is at every point.

Thank you for your help once more
#781
Posted: 07/20/2006 04:51:02
by Eugene Mayevski (EldoS Corp.)

Quote
Stephane Grobety wrote:
Supposing the host name doesn't match anything in the chain, how would I know which certificate is intended to be the end entity ? I suppose that I would need to read the store's "Chains" property and hope there is only one of them, right ?


If no certificate matches the host name, than the communication is fake and must be broken. Use of wrong certificate is non-sense. It's like you come and show a driving license issued to John Doe. I think you will be arrested :).

Quote
Stephane Grobety wrote:
I'm not using any of the system stores to validate these certificate so that means I'll have to build my own trusted roots store.


Probably yes. Certificate validation is quite a complex task.
Quote
Stephane Grobety wrote:
it could be helpful to add to the documentation a map of all the events that are firedt, in what order and what the session state is at every point


Both helpful and extremely time-consuming :).


Sincerely yours
Eugene Mayevski
#783
Posted: 07/20/2006 05:05:58
by Stephane Grobety (Priority Standard support level)
Joined: 04/18/2006
Posts: 170

Quote
If no certificate matches the host name, than the communication is fake and must be broken. Use of wrong certificate is non-sense. It's like you come and show a driving license issued to John Doe. I think you will be arrested Smile.


That's certainly true in the general sense but, unfortunately, I suspect that's what I'll have to do anyway (hoping I won't get arested for it :P).

You see: the final certificate will be sent to me by the remote host. In that specific case, I should limit my check to verify that this is indeed the same certificate and accept it no matter what the hostname is. In fact, the CN in the test site I currently have access to simply doesn't match anything that could be resolved so I don't have much of a choice.

Quote
Probably yes. Certificate validation is quite a complex task.


Indeed :/

Quote
Both helpful and extremely time-consuming :)


I understand, really. However, I would consider it time well-spent, though. As of today, everyone trying to undertstand how the compoennt is supposed to work and how to use it has to spend that time trying. If you do that in the documenattion, you'll need twice as much time as user spend today but you'l be spending it only once.

Anyway, it was just a suggestion. I understand that you're the one calling the priorities on this and I wouldn't dream of telling you how to use your ressources ;)
#813
Posted: 07/22/2006 02:47:42
by Eugene Mayevski (EldoS Corp.)

Quote
Stephane Grobety wrote:
First, I tried to connect without even attempting to verify anything in the certificate or use a local one. I discovered that the TElHTTPSClient component doesn't properly handle DATE headers that aren't in the GMT toime zone: as soon as the time zone section differs from "GMT", it reverts to the client's current date and time.


I have checked the specification, and time part MUST be GMT:

HTTP-date = rfc1123-date | rfc850-date | asctime-date
rfc1123-date = wkday "," SP date1 SP time SP "GMT"

So those servers are not standard-compliant.


Sincerely yours
Eugene Mayevski
#817
Posted: 07/22/2006 04:48:09
by Stephane Grobety (Priority Standard support level)
Joined: 04/18/2006
Posts: 170

Hm... You're right: the general rfc 1123 and 850 date format allows for other time zones but rfc 1945 /HTTP 1.0) and 2616 (HTTP 1.1) specify that only GMT timezone is allowed..

I'll take that to the serevr developper
Also by EldoS: CallbackDisk
Create virtual disks backed by memory or custom location, expose disk images as disks and more.

Reply

Statistics

Topic viewed 4570 times

Number of guests: 1, registered members: 0, in total hidden: 0




|

Back to top

As of July 15, 2016 EldoS Corporation will operate as a division of /n software inc. For more information, please read the announcement.

Got it!