[gPXE] Fwd: interrupt and serial

[Luca]

My assumption is that when gPXE starts it has a copy of the server
certificate. With this assumption, during the TLS handshake phase, when the
server sends the certificate I have gPXE comparing only the 2 public keys
(the one in the certificate the server just sent to gPXE and the one in the
certificate gPXE had when started).

When gPXE is done computing its premaster secret, gPXE sends it to the
server encrypted using the public key contained in the server certificate.
Because of that only the server can decrypt it.

So for me it is enough to compare just the public key.

The file where I do this comparison is net/tls.c, function
tls_send_client_key_exchange

Thanks,
 Luca

On Sat, Feb 13, 2010 at 8:40 AM, Peter Scheie <peter at scheie.homedns.org>wrote:

> I am interested in your code for comparing the https server's cert.  Your
> situation sounds similar to mine: I can provide the server's cert to gpxe
> during
> the initial setup (we'll be installing gpxe on the local disk and booting
> that
> and then chaining another script over https) so I just need to be able to
> compare the cert that the server provides to the one on the local disk.
>
> Peter
>
> Luca wrote:
> > On Tue, Feb 9, 2010 at 6:48 AM, Stefan Hajnoczi <stefanha at gmail.com>
> wrote:
> >
> >> On Tue, Feb 9, 2010 at 2:22 PM, Luca <lucarx76 at gmail.com> wrote:
> >>>> Let's discuss your setup and use case more.  Perhaps there is an
> >>>> existing solution or we can come up with a generic solution that can
> >>>> be merged into mainline gPXE.
> >>>>
> >>> I have an environment with several workstations, which I want to gPXE
> >> boot.
> >>> I have an environment with one DHCP server.
> >>> When gPXE starts, it gets from the DHCP server the path of the image it
> >>> should download.
> >>>
> >>> I want gPXE to be sure it's talking to the right server. So I modified
> a
> >>> little bit the gPXE TLS code. I assume gPXE has the certificate of the
> >> HTTPS
> >>> server it's going to talk to. During the TLS handshake, when the server
> >>> sends its certificate, I have gPXE validating it. If the certificate
> sent
> >> by
> >>> the server is the one gPXE has then gPXE knows it is talking to right
> >>> server.
> >>>
> >>> I have different HTTPS servers, and I want to be free to add a new one
> >>> whenever I need. So I do not want to have this certificate compiled
> into
> >>> gPXE.  That's why when gPXE starts I want gPXE to talk to a serial
> server
> >>> and get the certificate of the HTTPS is going to talk to.
> >> Other users have expressed interest in certificate validation and I
> >> think this is a general problem.
> >>
> >> I know little about how TLS works, but would it be possible to solve
> >> this by using a certificate authority instead of comparing against
> >> specific certificates?  When a client connects to a server, it will
> >> check that the server's certificate has been signed by the certificate
> >> authority?  That way you can support as many servers as you like, but
> >> they must be signed by the certificate authority (you).
> >>
> >
> > This is definitely an option. Option that I did consider.
> > It requires more changes in gPXE's code though that's why I was looking
> for
> > something else. But if there is no other way, using a CA authority is a
> > solution.
> >
> > Essentially if I have the server certificate in gPXE, during the tls
> > handshake it's just a matter of comparing the certificate the server
> sends
> > to gPXE with the one gPXE has.
> > If they match, encrypt everything with the public key contained in the
> > server certificate so that only the real server can decrypt the content.
> >
> >
> >>>> What are the constraints of your setup?  Do you have a DHCP server?
> >>>> Can you set the boot filename handed out by the DHCP server?
> >>>>
> >>> The communication between the serial server and gPXE is secure, while
> the
> >>> communication between gPXE and the DHCP is over an open channel. That's
> >> why
> >>> I do not want to pass this information to gPXE as a DHCP option.
> >> This is an interesting scenario: you do not trust the LAN.  What if
> >> the DHCP server hands out a http, tftp, etc URL instead of a HTTPS URL
> >> with your code in place?  I guess you have explicitly disabled all
> >> other protocols, including plain HTTP.
> >>
> >>
> > Yes I disabled all other protocols but HTTPS. gPXE won't boot anything
> > unless it comes from an HTTPS server gPXE trusts (i.e. gPXE has a copy of
> > server certificate or, if I add CA, CA confirms the certificate is ok).
> >
> >
> >> I am interested in your thoughts about secure network booting.  At the
> >> moment there are no "best practices" on the wiki.
> >>
> >>
> > Happy tho share with the gPXE community.
> >
> >
> >>>> When gPXE starts it could send a 'hello' message over the serial port
> >>>> and wait for a response.  The server would respond with the
> >>>> configuration.  I don't think there is a technical limitation
> >>>> preventing one from implementing this config-over-serial approach.
> >>>>
> >>> That's what I'm doing right now. The problem I have is that as I use
> >>> polling, sometimes I looses characters sent by the server (I do very
> few
> >>> operations when I get a character, but still sometimes I miss some
> >>> characters). This would not happen if I used interrupts.
> >> Without seeing the code I can't be sure what is going on.  However,
> >> adding interrupt handlers to the mix is not going to make the code go
> >> any faster.  If you currently have a tight receive loop and it is
> >> missing characters, then something is wrong.  Is the baud rate set
> >> correctly on the serial port?
> >>
> >>
> > If I had interrupts, I could stop anything I'm doing every time I get a
> new
> > character and put it into a buffer and then go back to what I'm doing. So
> I
> > shouldn't miss any character.
> > If I use polling, even if the loop is tight, if I get more characters
> while
> > I'm in the loop, I might miss something (when I poll the serial might be
> too
> > late).
> > But I might be wrong so having the interrupts would not change the
> > situation.
> >
> > Yes the baud rate is set correctly. Most of the time (I would say 90% of
> the
> > time) it works. But sometimes I miss characters.
> >
> >
> >> Stefan
> >>
> >
> > Luca
> >
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > gPXE mailing list
> > gPXE at etherboot.org
> > http://etherboot.org/mailman/listinfo/gpxe
> _______________________________________________
> gPXE mailing list
> gPXE at etherboot.org
> http://etherboot.org/mailman/listinfo/gpxe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://etherboot.org/pipermail/gpxe/attachments/20100215/cfe803cd/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tls.c
Type: text/x-csrc
Size: 57820 bytes
Desc: not available
Url : http://etherboot.org/pipermail/gpxe/attachments/20100215/cfe803cd/attachment-0001.bin