• My Project Proposal

Have almost finished porting the MatrixSSL versions of SHA1 and MD5. (Just one function I have to track down). Going to work on RSA next and see how small we can get it. Update: I took a look at 3DES, and even though the code is large (due to constant arrays) it should be easy to port. RSA is being a pain.

From openssl.org faq “Typically you'll see a message saying there are no shared ciphers when the same setup works fine with an RSA certificate. There are two possible causes. The client may not support connections to DSA servers most web browsers (including Netscape and MSIE) only support connections to servers supporting RSA cipher suites. The other cause is that a set of DH parameters has not been supplied to the server.” Because of this, I am going to look into the RSA algorithm and see how small it can be.

The CipherSuites that mod_ssl accepts depends on what algorithms openssl was compiled with. Then in httpd.conf there is a directive that specifies which algorithms to accepts, or reject, and the default is to reject Anonymous DiffieHellman Suites. I will try to figure out which CipherSuites are avaliable on the default config.

News! CreateSSLHello is functional, creating a ssl client hello message that is accepted by any ssl server. Ran into a problem though. Based on size constraints I have selected 4 Cipher Suites that could be used with minimal space (SSL_DH_DSS_EXPORT_WITH_DES40_CBC_SHA, SSL_DH_DSS_WITH_DES_CBC_SHA, SSL_DH_anon_EXPORT_WITH_RC4_40_MD5, SSL_DH_anon_WITH_RC4_128_MD5). The problem is these are not the most common Suites used, for example my basic install of Apache with SSL enabled does not accept any of these. So either we select some more Suites or the server admins will have to enable more Suites. I will figure out how to add these Suites to Apache shortly and post some more information.

Outline of SSL Code Structure

When a person starts coding a protocol using the SSL Library the code will follow this basic outline.

• Create an SSL struct
• Call an SSL startup function (maybe make this part of gPXE startup)
• Call CreateSSLHello to fill a buffer with the required ClientHello message
• (send buffer through connection, and read response)
• Call ReadSSLHello and pass the filled buffer
• (send buffer through connection, and read response)
• Call FinishSSLHello and pass the filled buffer
• ——————–
• Call SSLEncode / SSLDecode and pass a buffer for the encrypted / decrypted text
• ——————–
• Call SSLShutdown method to create the close message
• (send buffer through connection)
• Call SSLEnd method to free data structures / memory

Note: Function names are just placeholders

Note: After each call to an SSL function the programmer needs to check for an error (there are several). For example (need to read more data, connection closed, etc.)

I'm working on reading through the SSL v3.0 RFC. Trying to work with only the code from MatrixSSL was not going to get me that far, as I did not understand what was going on at the lowest levels. I am about half way done with reading the RFC. Once I am done, I can start creating the different code frameworks that are used by SSL.

So I have been looking through the SSL protocol setup communication. It looks like the client is not required to have an X.509 Certificate and private key. This allows us to do one of two things:

1. Remove code that deals with handling the client key and certificate
2. Insert the code (from #1) and allow the server to verify the identity of the client that is booting

I am working on adding security into gPXE. There are several different ways to do this. At the moment I am working on adding the ability to use SSL with different connection methods (TCP/UDP/etc.) to create a secure connection over which you can download the needed files. I will be using MatrixSSL as the bases for my SSL library.

To make sure that this SSL implementation is as connection independent as it can be, I will be making several functions that will construct the SSL messages in a supplied buffer. Then it will be up to programmer to send the buffer throught the used connection. There will also be functions to encode and decode data that is being sent over the connection. Since these function will use minimal internal memory and the programmer provides the buffers, the footprint for the library will be minimal.

• Saturday June 24 - Finish mapping MatrixSSL design. Have communication flow layout. Finish setting up a testing setup, including a framework for testing code.
• Wednesday July 5 - Finish SSL key handling code.
• Saturday July 15 - Finish SSL handshake code.
• Wednesday July 26 - Finish SSL encode / decode code.
• Saturday August 5 - Finish SSL teardown code.
• Wednesday August 16 - Debug, Clean up code, etc.
• Monday August 21 - Buffer.

• Integrate SSL Library into gPXE code base.
• Create HTTPS (or similar) protocol, that used the SSL Library to create a secure network connection.