Improve SSL support about h2o HOT 12 OPEN

• session cache
• load intermediary CA certs

from h2o.

• configurable list of ciphersuites

from h2o.

note: H2O supports session resumption (OpenSSL by default uses a in-memory session cache).
https://www.openssl.org/docs/ssl/SSL_CTX_set_session_cache_mode.html

from h2o.

• server name indication

from h2o.

• SSL false start

from h2o.

The question is whether if we need to implement dynamic TLS record sizing, considering the fact that the overhead of limiting TLS record size to 1,400 bytes is around 2% (overhead per TLS record is (at minimum) 26 bytes in case of SHA1 or 29 bytes in case of current implementation when using 128-bit block cipher in CBC mode).

from h2o.

Support building against PolarSSL:
https://polarssl.org/

from h2o.

@hedgehog is there any reason where PolarSSL is favorable (e.g. faster on ARM?)?

At the moment, I am thinking that switching from OpenSSL to LibreSSL might be a good idea (as IIRC it supports things like ALPN which is still beta in OpenSSL).

from h2o.

Note that PolarSSL is GPL.
See:

• https://polarssl.org/kb/licensing/using-polarssl-in-a-non-gpl-project
• https://polarssl.org/kb/licensing/why-use-the-gpl-license-instead-of-license-xyz

from h2o.

@kazuho, the reasons is related to arm, but not necessarily just speed.
Supporting PolarSSL would mean a system could avoid having to install OpenSSL, which reduces bloat. - which is a consideration in ARM systems.

Regarding Licensing:

• Polar SSL has an exemption for the WTFPL

I've always thought the WTFPL license is as unambiguous as you can get. The legal version of the coders ode to minimal code "No code is faster than no code".... "No licence condition is clearer than no conditions"

Beside you even get enterprise grade logo support for free:

I should add the license permits removing the expletive, as long as you rename it.

from h2o.

@hedgehog Thank you for the clarification.

Supporting PolarSSL would mean a system could avoid having to install OpenSSL, which reduces bloat. - which is a consideration in ARM systems.

Understood. I am not excluding the possibility that libh2o will be used in embedded systems, for which favoring a smaller (and less complex) TLS implementation than OpenSSL would be a good idea. However as discussed in #90 (comment) that is not my (or my employiers) primary interest. So it is unlikely that I would add support for PolarSSL myself.

Polar SSL has an exemption for the WTFPL

Is my understanding right that the license exception only covers FOSS applications that are linked against PolarSSL? If that is the case, people would not be possible to link libh2o (using PolarSSL as the TLS implemenatation) to their commercial, non-open-source programs. IMO that may become a obstacle for people trying to use libh2o (+PolarSSL) on the embedded systems.

note: I am not against the idea of adding support for PolarSSL, I just want to make the differences clear.

from h2o.

FYI... PolarSSL is in the process of moving into mbedTLS1 which brings a change of license to the more permissive Apache license.

from h2o.