EldoS | Feel safer!

Software components for data protection, secure storage and transfer

Problem adding Cert during TElSSLServer OnExtensionsReceived event

Also by EldoS: Rethync
The cross-platform framework that simplifies synchronizing data between mobile and desktop applications and servers and cloud storages
#35270
Posted: 12/22/2015 03:48:08
by Matt matt (Standard support level)
Joined: 12/22/2015
Posts: 11

Hi,

I'm just evaluating at the moment and all looking good apart from one issue.

I want to add a certificate to the TElMemoryCertStorage during the OnExtensionsReceived event of the TEISSLServer, based on the PeerExtensions.ServerName.

What I've found however is that I can't seem to add the certificate during this event.

I can add the certificate before or after the Open like this

_server.CertStorage.LoadFromBufferPFX(_bytCert, "none");
_server.Open();


and it works fine,

however if I do this....


_server.OnExtensionsReceived += _server_OnExtensionsReceived;
_server.Open();


void _server_OnExtensionsReceived(object Sender)
{
_server.CertStorage.LoadFromBufferPFX(_bytCert, "none");
}


...it doesn't work and I get a fatal local error code number 75803 back through the OnError event

Please can suggest a fix or workaround?

Many thanks,
#35271
Posted: 12/22/2015 04:18:30
by Ken Ivanov (EldoS Corp.)

Hi Matt,

Thank you for contacting us.

TElSSLServer checks the list of available server certificates during cipher suite negotiation routine, which is performed before OnExtensionsReceived fires. This is because the component needs to inspect their public keys to make sure that a particular cipher suite can be used.

If you need to adjust server certificates basing on the contents of Server Name extension, it makes sense to add all your certificates before calling Open() and then remove the ones that don't match the server name from within the OnExtensionsReceived handler. Alternatively, you can use a dummy certificate with the key of the same type as your real certificates have (e.g. RSA), adding it to the storage before calling Open(), and replacing it with a proper certificate in the OnExtensionsReceived handler.

Still, I agree that both approaches are subject to certain level of awkwardness, so we'll think what we can do to make the selection process easier.

Ken
#35272
Posted: 12/22/2015 05:25:52
by Matt matt (Standard support level)
Joined: 12/22/2015
Posts: 11

Hi Ken,

Thanks for your quick response.

Unfortunately I don't know any of the server names before hand. I'm running the application as a packet inspection gateway/firewall and then generating the (auth signed) certificates as required. I've already got an implementation for this, but I'm looking for a more stable and complete SSL suite and this looks like it's it (with other toys too!) - just need this bit to work.

Could you please explain this a bit more if possible if it's suitable for the task above?

Quote
Alternatively, you can use a dummy certificate with the key of the same type as your real certificates have (e.g. RSA), adding it to the storage before calling Open(), and replacing it with a proper certificate in the OnExtensionsReceived handler.


On a possible work around, if I buy the package, I get the source correct? I assume it's then fairly possible hack in a change to event out the server name early?
#35273
Posted: 12/22/2015 05:37:12
by Matt matt (Standard support level)
Joined: 12/22/2015
Posts: 11

Quote
Alternatively, you can use a dummy certificate with the key of the same type as your real certificates have (e.g. RSA), adding it to the storage before calling Open(), and replacing it with a proper certificate in the OnExtensionsReceived handler.


Right, it's just dawned on my what you meant....

Yes.. that works great..... Thank you for suggesting it!

If it helps anyone else, do what Ken said above...

//create temporary one here.
_server.CertStorage = new TElMemoryCertStorage();
_server.CertStorage.LoadFromBufferPFX(bytCertTemp, "none");


_server.OnExtensionsReceived += _server_OnExtensionsReceived;
_server.Open();


void _server_OnExtensionsReceived(object Sender)
{
//replace it here as long as all the indexes match.......
_server.CertStorage = new TElMemoryCertStorage();
_server.CertStorage.LoadFromBufferPFX(bytCert, "none");
}


Thanks again.....

Matt.
#35276
Posted: 12/22/2015 05:54:56
by Ken Ivanov (EldoS Corp.)

What I mean is that on the early stage of the TLS client hello processing - i.e. before OnExtensionsReceived is fired - the component only needs to know the types of available private keys, not the keys themselves (the keys are extracted and used later on). For example, when deciding if SB_SUITE_RSA_AES256_SHA cipher suite is at all usable, the components checks if CertStorage contains any certificates with an RSA key. Similar checks are performed for other key exchange and signature algorithms (DSA, ECDSA, DH). In the above example, if no RSA certificates are available on that stage, the SB_SUITE_RSA_AES256_SHA cipher suite is switched off, and so are the rest of RSA-driven cipher suites. That's why you are getting the 75803 (ERROR_SSL_NO_SHARED_CIPHER) error.

That is, if your 'real' domain certificates come with RSA keys, you can add a dummy certificate containing an RSA key before calling Open() so that the preliminary key type check succeeded. You will then replace that dummy certificate with your real one in OnExtensionsReceived handler, making the correct certificate and key used later during the negotiation.

For RSA keys you can use the sample certificate included in SecureBlackbox distribution (cert.pfx) as a dummy certificate.

Quote
On a possible work around, if I buy the package, I get the source correct? I assume it's then fairly possible hack in a change to event out the server name early?

Yes, it would be fairly easy to tune that up. Still, I doubt that you will ever need that, as we are going to implement a better handling for certificate choosing in the next product update.
#35277
Posted: 12/22/2015 05:57:19
by Ken Ivanov (EldoS Corp.)

Matt,

That's exactly what I meant - glad that you've managed to make it work for you!

We will be improving that part anyway in near future to make the code more straight.

Ken
Also by EldoS: Callback File System
Create virtual file systems and disks, expose and manage remote data as if they were files on the local disk.

Reply

Statistics

Topic viewed 1402 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!