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 <[email protected]> wrote: > >> On Tue, Feb 9, 2010 at 2:22 PM, Luca <[email protected]> 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 > [email protected] > http://etherboot.org/mailman/listinfo/gpxe _______________________________________________ gPXE mailing list [email protected] http://etherboot.org/mailman/listinfo/gpxe
