11 sec per https:// connection?

[harryc]

I'm missing something, but I can't begin to guess what it is, I need help.
First I set up an insecure http connection between a kvm virtual machine guest with a blank little disk and Seabios garden variety pxe. DHCP served up an iPXE and further http:// requests were sub-second quick to establish. Large files transfer at near link speed. So far, so good.

Next I cooked up a 2048 bit RSA ca, nginx server cert, and built a ipxe with a 2048 bit private key. The ipxe has an embedded private key, embedded client cert, and embedded ca.
the ca does point to a local http:// server holding a certificate revocation list / crl. I have no idea whether the ipxe client checks the crl for the server's cert, but I know the server checks the ipxe cert against the crl before beginning the secure session.

When I issue an ipxe https:// request, the thing sits there for 10.7 seconds, then begins the transfer, which appears to complete quickly. I actually can't be sure it is the setup that takes 10.7 second or whether it does that quickly, loses its place somehow, then recovers and does the transfer.

Anyhow: The nginx setup ssl section is:

ssl_session_timeout 5m;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers AES256-SHA256:AES256-SHA;
ssl_prefer_server_ciphers on;
ssl_verify_client on;
ssl_session_cache shared:ssl:2m;
ssl_verify_depth 1;

When I read the docs I was prepared for a 1 second added delay per transaction. 10.7 sec is a project killer delay. Occasionally I'll get a timeout on the ipxe side before the transfer completes. What am I missing? Why does it take so long to set up a https:// session?

While we're at it, does iPXE support the idea of reusing the setup of a SSL request completed moments before? Or is there no way to reuse and avoid the setup lag for subsequent quick https requests to the same server?

Thanks for any ideas!

[mcb30]

(2015-04-18 02:55)harryc Wrote:  I have no idea whether the ipxe client checks the crl for the server's cert

iPXE will check revocation status of the server certificate via OCSP, if the certificate includes an OCSP URI. There is no way to use a CRL instead of OCSP, because CRLs are simply not practical for a bootloader which has to operate with no way to store non-volatile state. (You'd end up having to download the whole CRL each time, which would be basically equivalent to using OCSP but transferring vastly more data than necessary.)

Quote:When I read the docs I was prepared for a 1 second added delay per transaction. 10.7 sec is a project killer delay. Occasionally I'll get a timeout on the ipxe side before the transfer completes. What am I missing? Why does it take so long to set up a https:// session?

It's the 2048-bit client private key which is most likely causing your delay. iPXE's code is optimised for size rather than speed. Signing with a private key is a very expensive operation. (Verifying with a public key is usually fast, since most real-world RSA key pairs use a small and simple public key such as 0x10001).

You could use HTTPS without a client certificate and should see no perceptible slowdown over plain HTTP.

If you want to retain the client certificate, then you could reduce the strength of the client private key (e.g. to 1024 bits) and should see a substantial speed increase over the 2048-bit case.

Quote:While we're at it, does iPXE support the idea of reusing the setup of a SSL request completed moments before? Or is there no way to reuse and avoid the setup lag for subsequent quick https requests to the same server?

iPXE currently has no way to use HTTP keepalive between different downloaded files. (It does have some support for keepalive, but only when using sanboot, which establishes a single HTTP connection and then uses range requests to retrieve disk blocks as required.)

iPXE does cache SSL certification validation results so, for example, you won't have to wait for OCSP validation round-trips on the second download from the same HTTPS server. This caching doesn't help with the slowdown due to the use of the client certificate, since that requires a fresh RSA signing operation for each connection.

Hope that gives you some options. Adding generic keepalive support would be viable (and probably desirable; the HTTP code could do with some refactoring), but would be at least a week's work.

Michael