To add more parameter for my http header for SSL/TLS

As far as I understand, https is http plus SSL/TLS.

What do I need to do if I want to add 3 more parameters for the header? I found a file inside Mozilla's NSS - ssl3ext.c, but I don't understand it and don't know how to start. Need a开发者_C百科 clue from you guys..

Is this something about SSL/TLS extension? But it is far more complex right?

---

SSL/TLS is a transport layer. It's negotiated first, and then HTTP talks "over" it. To add more HTTP header parameters you do exactly the same as you would normally.

(to be completely clear - HTTPS is HTTP "on top" of TLS/SSL. The TLS/SSL connection is made first and then HTTP uses it just like it would use an unencrypted transport).

---

if a developer would like to add some more information/parameters for his SSL communication/handshaking, where does the parameter should be located?

RFC 3546 'Transport Layer Security (TLS) Extensions' is the only defined way to add additional parameters to the SSL/TLS handshake.

You can add your extension to the Client Hello message. If the server recognizes it, it can respond with a corresponding extension on the Server Hello message. The server cannot send it unless it was requested, however.

is it inside the code for http header or is it creating a new extension for TLS like the server name indication(SNI)?

It has nothing to do with HTTP. The SSL/TLS handshake is over before HTTP even begins.

I have looked into the code and RFC for SNI but seems does not get any clues?

Look at RFC 3546 for the extension format. The IANA manages the extension numbers. http://www.iana.org/assignments/tls-extensiontype-values/ Note that there is no 'experimental' range for you to use. IMHO what you do over your own ports is your own business, but be aware of the possibility of conflict in the future.

Does adding more parameters to the handshaking process will disturb the current implementation?

Some SSLv3 and older TLS 1.0 servers will hang up on you if you send an extension they don't like. Major web browsers implement fallback reconnect logic without extensions.

will it broke the standard?

If your extension follows the general format for extensions defined in RFC 3546, the only (modern) standard you are breaking is that you are not using an IANA-blessed extension ID number. If your extension is generally useful, you should strongly consider submitting it for formal standardization.

---

You can add as many HTTP header parameters as you like, without concern for SSL. If you want to modify the SSL handshake, you should have the source to your SSL libraries on both sides of the connection.

I'm not sure what your trying to do here though. You could modify the ClientHandshake to include more/customer cipher suites. You could also define a custom content type. Currently the first byte in a TLS record determines the content type, which are as follows:

0x14    20  ChangeCipherSpec
0x15    21  Alert
0x16    22  Handshake
0x17    23  Application

Depending on what you are trying to do, you may be well served by adding a custom alert to the Alert Protocol. Alerts can be sent at any time, in either direction.

Customizing the protocol will break the standard, though you can do things like add cipher suites without changing the protocol. Between client certs and server certs, the protocol generally has everything most people need for authentication and encryption.