On Tue, Feb 9, 2010 at 6:48 AM, Stefan Hajnoczi <span dir="ltr"><<a href="mailto:stefanha@gmail.com">stefanha@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On Tue, Feb 9, 2010 at 2:22 PM, Luca <<a href="mailto:lucarx76@gmail.com">lucarx76@gmail.com</a>> wrote:<br>
>> Let's discuss your setup and use case more. Perhaps there is an<br>
>> existing solution or we can come up with a generic solution that can<br>
>> be merged into mainline gPXE.<br>
>><br>
> I have an environment with several workstations, which I want to gPXE boot.<br>
> I have an environment with one DHCP server.<br>
> When gPXE starts, it gets from the DHCP server the path of the image it<br>
> should download.<br>
><br>
> I want gPXE to be sure it's talking to the right server. So I modified a<br>
> little bit the gPXE TLS code. I assume gPXE has the certificate of the HTTPS<br>
> server it's going to talk to. During the TLS handshake, when the server<br>
> sends its certificate, I have gPXE validating it. If the certificate sent by<br>
> the server is the one gPXE has then gPXE knows it is talking to right<br>
> server.<br>
><br>
> I have different HTTPS servers, and I want to be free to add a new one<br>
> whenever I need. So I do not want to have this certificate compiled into<br>
> gPXE. That's why when gPXE starts I want gPXE to talk to a serial server<br>
> and get the certificate of the HTTPS is going to talk to.<br>
<br>
</div>Other users have expressed interest in certificate validation and I<br>
think this is a general problem.<br>
<br>
I know little about how TLS works, but would it be possible to solve<br>
this by using a certificate authority instead of comparing against<br>
specific certificates? When a client connects to a server, it will<br>
check that the server's certificate has been signed by the certificate<br>
authority? That way you can support as many servers as you like, but<br>
they must be signed by the certificate authority (you).<br></blockquote><div><br>This is definitely an option. Option that I did consider. <br>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.<br>
<br>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. <br>If they match, encrypt everything with the public key contained in the server certificate so that only the real server can decrypt the content.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
>> What are the constraints of your setup? Do you have a DHCP server?<br>
>> Can you set the boot filename handed out by the DHCP server?<br>
>><br>
><br>
> The communication between the serial server and gPXE is secure, while the<br>
> communication between gPXE and the DHCP is over an open channel. That's why<br>
> I do not want to pass this information to gPXE as a DHCP option.<br>
<br>
</div>This is an interesting scenario: you do not trust the LAN. What if<br>
the DHCP server hands out a http, tftp, etc URL instead of a HTTPS URL<br>
with your code in place? I guess you have explicitly disabled all<br>
other protocols, including plain HTTP.<br>
<br></blockquote><div><br>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).<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I am interested in your thoughts about secure network booting. At the<br>
moment there are no "best practices" on the wiki.<br>
<div class="im"><br></div></blockquote><div><br>Happy tho share with the gPXE community.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">
>> When gPXE starts it could send a 'hello' message over the serial port<br>
>> and wait for a response. The server would respond with the<br>
>> configuration. I don't think there is a technical limitation<br>
>> preventing one from implementing this config-over-serial approach.<br>
>><br>
><br>
> That's what I'm doing right now. The problem I have is that as I use<br>
> polling, sometimes I looses characters sent by the server (I do very few<br>
> operations when I get a character, but still sometimes I miss some<br>
> characters). This would not happen if I used interrupts.<br>
<br>
</div>Without seeing the code I can't be sure what is going on. However,<br>
adding interrupt handlers to the mix is not going to make the code go<br>
any faster. If you currently have a tight receive loop and it is<br>
missing characters, then something is wrong. Is the baud rate set<br>
correctly on the serial port?<br>
<font color="#888888"><br></font></blockquote><div><br>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. <br>
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). <br>But I might be wrong so having the interrupts would not change the situation.<br>
<br>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.<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<font color="#888888">
Stefan<br>
</font></blockquote></div><br>Luca<br>