[ipxe-devel] [tls] received overlength Handshake - GoDaddy certs

Christian Nilsson nikize at gmail.com
Sat Jan 19 09:04:35 UTC 2019


I have not looked at the code at all so this might be very simple, but
will still ask ;)
Is there any way to detect that you only got a partial TLS header? or
is it any way to detect that it isn't complete and we should wait for
more data before processing it?
(i guess that is the extension you mention?)

It might be that large parts of the certificate code needs to be
rewritten to handle this (while still considering memory constraints)

I think this has been reported before, just that not enough
information was provided to reproduce, and/or not persistence was put
in to have it fixed.

On Fri, 18 Jan 2019 at 21:18, Sebastian Roth <sebaroth at gmx.de> wrote:
>
> Hey,
>
> trying to tackle this myself I got a little further. From what I
> understand the GoDaddy certificate (probably the whole chain together)
> is longer than 4096 bytes causing the TLS handshake to be fragmented
> into two portions as max_fragmentation_length extension is used and set
> to 4096 [1]. Removing that TLS extension from the client request solves
> the issue I see with GoDaddy certs right away but would leave us with a
> high memory footprint as described in the commit message [1].
>
> The issue as I see it is that iPXE proceeds with handling the first 4096
> byte blob of data as TLS_CERTIFICATE handshake although more data from
> the subsequent TLS record needs to be processed as well.
>
> I am wondering that this has not been reported by anyone else so maybe I
> am on the wrong track with this. But having dug through the code for
> hours now I am fairly sure about it. I just don't seem to be able to fix
> this by myself as I don't know the IO buffer handling and other things
> involved well enough.
>
> See below for hints on how to reproduce the issue - fairly easy.
>
> Regards,
> Sebastian
>
> [1]
> https://git.ipxe.org/ipxe.git/commit/9a8c6b00d4433eb5c24f50c0c4a93c127d77def0
>
>
> On 12/14/2018 06:44 PM, Sebastian Roth wrote:
> > Hey,
> >
> > we are using iPXE to chainload from HTTPS which works fine in most cases
> > but fails with GoDaddy certificates. As suggested in the iPXE forums I
> > am going to post this to the devel list as well. Hope you don't mind me
> > cross posting.
> >
> > Steps to reproduce:
> >
> > * clone latest ipxe git repo
> >
> > * enable DOWNLOAD_PROTO_HTTPS in general.h and maybe adjust other other
> > defines for your needs
> >
> > * Download GoDaddy CA and intermediate cert:
> > https://certs.godaddy.com/repository/gdroot-g2.crt and
> > https://certs.godaddy.com/repository/gdig2.crt.pem
> >
> > * embedded script:
> > #!ipxe
> > dhcp
> > chain https://www.godaddy.com/
> > (I know there is nothing to chainload there but it's just an example for
> > a domain using a GoDaddy cert)
> >
> > * make bin/undionly.kpxe EMBED=chain DEBUG=tls
> > TRUST=/path/to/gdroot-g2.crt,/path/to/gdig2.crt.pem
> >
> >
> > Now booting this fails with "Invalid argument
> > (http://ipxe.org/1c0de802)". When disabling some of the debug dump
> > output (src/net/tls.c line 1810) I see the last message to show TLS ...
> > received overlength Handshake.
> >
> > If I comment/skip the "return -EINVAL_HANDSHAKE" in line 1811 it
> > proceeds but fails on TLS ... overlength certificate (src/net/tls.c line
> > 1591)this time.
> >
> > Seems like len/remaining variable is set to 4096 (iob_len) and that
> > truncates the long (5286 bytes) SSL handshake record / certificate.
> >
> > I have looked through the code a bit but I am afraid I will break things
> > when I play with io buffer length stuff. Anyone an idea?
> >
> > Thanks in advance,
> > Sebastian
> > _______________________________________________
> > ipxe-devel mailing list
> > ipxe-devel at lists.ipxe.org
> > https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel
> >
>
> _______________________________________________
> ipxe-devel mailing list
> ipxe-devel at lists.ipxe.org
> https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel



More information about the ipxe-devel mailing list