11 sec per https:// connection?

[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