I'm writing protocol that encrypts whatever is being sent using TLS. For TLS, I'm using schannel on Windows.
For testing, I'm connecting to IIS, doing GET, and connecting using Chrome to my server, just sending back HTTP 200 response.
However, there are few edge cases I'm unable to check with this. I want to use someone else's implementation for reference, so I don't end up with bogus implementation on both sides.
Is there any testing TLS server (client), which can I use for testing
renegotiation
partially sent message
extra data in handshake / message (DecryptMessage to have filled SECBUFFER_EXTRA buffer)
?
Thanks.
Related
I have a RESTful API and when I use a web browser, IE Chrome or Firefox, to send a GET request I noticed that the browsers sometimes opens 2 connections. One connection seems to always get to the change cipher finished part of the SSL handshake and then closes connection before request can be completed. The other connection is able to get past the change cipher finished part of the SSL handshake and complete the GET request. Which connection fails doesn't depend on which connection was established first.
Why are the browsers sending the 2 request? Why is it dropping one of the request after the change cipher complete part of the SSL handshake?
I would post image of packet capture, but I do not have enough reputation to do that. Any help on this would be much appreciated.
Well, the title says it all. For testing purposes I need that each SSL session will renegotiate its encryption parameters. Can I configure Fiddler in such a way to always decline a client's request to reuse previously negotiated encryption params, and force it to negotiate new ones?
Unfortunately, I don't know any way to force SChannel (the stack under System.Net.Security's HTTPS implementation) to do that.
One quick thing to remember is that when you have HTTPS decryption enabled there are two HTTPS connections in this scenario-- one from the client to Fiddler and one from Fiddler to the server.
I configured SSL mechanism in tomcat 6 by generated certificate using java keytool with RSA algorithm and I’m able access the urls using the HTTPS.
Now I have few doubts
While communicating client with server (browser to server or server to browser), is Data also encrypted using 128 bit encryption?
If stand alone application is communicating with server do I get encrypted data only?
Please clarify my doubts. Thanks in advance
Yes, once the SSL connection has been negotiated (which is the first thing that happens), all data (client and server) is encrypted.
Any application communicating over an SSL-secured channel will have all its data encrypted and (because of certificate signing) it will be relatively confident that it's speaking with the actor it thinks it should be speaking with (ie, it will have protection against MITM attacks).
If you're connecting with an SSL-enabled client (whether that's a browser, libcurl, or something else) to whatever port you have configured for SSL, your entire communication path will be encrypted. If you try to connect with a non-SSL-enabled client to an HTTPS listener, you'll get a Bad Request error message like this:
Your browser sent a request that this server could not understand.
Reason: You're speaking plain HTTP to an SSL-enabled server port.
Instead use the HTTPS scheme to access this URL, please.
If you're really concerned, try using something like Wireshark to view the communication between client and server.
is there a way for some one to sneak in the to see data if my service is over http and the caller in my case is hosted on http (i.e. service is on secure ssl host while caller is on simple http).
is that call secure or not?
Basic HTTP without any encryption or other means of obfuscating your content is just plain text going over the wire. Anyone with a bit of knowledge can trap that connection and just read everything that goes on.
I don't quite understand what you mean by the server is on secure host but the client is not? Either the conversation between those two is secured by SSL / HTTPS (but then BOTH ends need to participate), or not. If not - it's just clear text on the wire.
Yes if someone is able to sneak into your transmissions, they can workout if the messages are encrypted or not.
When you connect to a server marked with server side SSL (server marked with https), it sends a copy of its cert to the client (e.g. your browser) which verifies if its a genuine cert. This only confirms that the server is really what it says it is and not someone else masquerading.
This does not guarantee that no can intercept your message. They can intercept but wont be able to decrypt.
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 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.