[gPXE] Fwd: interrupt and serial

[Peter Scheie]

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