On 10/04/17 12:27, Peter Wagemans wrote:
It doesn't seem to take into account that the payload_len of the
handshake message can be bigger than the received TLS record and will
continue in a subsequent TLS record. Unfortunately, that is the case
in the current setup of the tested Satellite server.
Can you confirm this theory about a handshake failure mechanism?
Your theory is correct. iPXE does not support fragmentation reassembly
of non-data records. We could potentially add this feature.
If the code is indeed the culprit, then a workaround is probably to
reconfigure the Satellite server to either not ask for client
certificates on the URLs that iPXE retrieves,
That can't work since you don't know the URL until after the handshake
has completed. (If you are using a completely different virtual host
then you could use the SNI to trigger this behaviour.)
or to configure a smaller list of acceptable client certificate CAs.
That should work.
Michael
_______________________________________________
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel
