Daniel Stenberg wrote:

>> and finally another question which unfortunately Patrick was not able

>> to
>> answer: what about the AS400 SSL support? We dont know yet if this
SSL
>> toolkit supports SNI too...

> Well, we should of course still work fine even if it doesn't. It
certainly wouldn't surprise me if yassl doesn't support it either!

Some precisions about OS400 SSL:

_ The current OS400 curl SSL implementation is based on an API package
named "QsoSSL" (QSSL in curl for short) that is private to OS400,
synchronous only and NOT reentrant. In addition, it allows only one SSL
context per application. It uses "certificate stores" that are managed
by the OS400 system software rather than certificate is stream files.

_ I checked this API for some SNI capabilities... Without success.
Although I cannot check if RFC-4366 extensions are handled at
The protocol level, I am sure there is no support in this API for a
client to provide an SNI name before handshake.

_ There is another SSL API on OS400: it is named GSKit. Its main
advantages compared to QsoSSL are: reentrancy, multiple contexts and
asynchronous operations. It uses the same "certificate stores" as
mentioned above... and still not feature a way to provide an SNI
identifier. There is a settable property called "GSK_CSP_NAME": the only
info for it (until now) is "not supported"... thus I wonder if the
intention for such an option is SNI... Wait for IBM and see !

_ Last but not least, I check the OS400 version V6R1 that is released
for two weeks now: no addition to (both) SSL API that may help
implementing SNI.

In short: GSKit would be better than QsoSSL, but harder to code (and I
do not have time for it now: if some OS400 guy wants to do it, do not
hesitate!). In any case, SNI option will be disabled in OS400 libcurl.

Patrick
Received on 2008-02-12