I know generally how HTTPS works, and from what I read, it seems that the generation of the encryption key could be done by a computer that isn't the one establishing the connection.
My thought is to create a proxy that isn't actually able to see the traffic going over the SSL connection. To do this, you would have a handshake in the same way as usual between the proxy and the server. However you would pass the encrypted symmetrical key to the proxy from your computer who would then transmit it on to the server. Then, when the server returned an encrypted payload, the proxy would not be able to decrypt it, but would forward it on to the users computer.
Am I missing something fundamental about how HTTPS works?
Related
I'm working on designing a server, in which the protocol allows for the client to open additional physical connections to the server which operate in the context of a single logical connection.
One thought I had was that, if we're using ssl, we'll need to do another ssl handshake for the new connection. It seems to me that it should be possible to send some secret to the client over the original, secure connection that would allow the new connection to be securely established without a handshake (similarly to what I've read about ssl session reuse).
Is this actually possible?
SSL already does this. Provided both ends support it, there is a feature called 'session resumption' which allows a new connection via an existing SSL session, via a much abbreviated handshake, without the certificate exchange and negotiation of shared secrets.
Yes, by reusing SSL Session. You can do this by using PEM_write_bio_SSL_SESSION and PEM_read_bio_SSL_SESSION and then adding it to SSL Context.
Keep in mind you only need to do this in client mode, server mode does this automatically for you.
Would like to write SSL Socket client server application on the same machine (both server and clients are running same machine). Should I use SSL certificate file (.pem file ) or not required.
Just I want encrypt the data before sending via socket.
Can we encrypt the data without .pem file?
Please advice me.
-Bala
SSL has two major steps:
check the identity of the peer, e.g. make sure you talk to the right one and not an imposter (e.g. man in the middle). This is done with certificates.
encrypt the connection, so that anybody listening on the wire cannot understand what's going on. Obviously encryption helps nothing if somebody is actively listening on the wire, because you failed in step#1. In this case you have no end-to-end encryption but an end-to-imposter and imposter-to-end encryption :)
Considering these arguments: do you still want to skip checking the certificate?
If you want it is doable, just look for anonymous authentication, e.g. ADH or aNULL with openssl.
Is this possible?
My understanding goes as far as this:
A non-proxy aware client will negotiate SSL directly with a listener, without every sending a CONNECT request to identify the destination host. A transparent proxy would need a destination host in order to forge a certificate with the hostname for the client.
I've read that some browser support the "server_name" extension in the client hello message which will identify the destination host and that if the extension is present this can be done. However, I'm unaware which browsers if any support this extension.
I would think that this should be possible but my efforts so far using squid and burp haven't been successful.
I understand that there's no way to obtain the destination host in the initial connection phase but I would think that with the correct configuration it would be possible to allow a forwarded connection in the initial phase then capture the returned certificate in order to read the destination then be able to inject the proxy's own CA-signed certificate at this point with the hostname derived from the legitimate certificate.
I think the best bet to get this working (if it's at all possible) is using squid's bump-server-first method http://wiki.squid-cache.org/Features/BumpSslServerFirst
I'm interested to hear if anyone has ever successfully gotten this to work.
I have a couple questions about SSL.
What happens if someone tampers or changes the encrypted data? There are many ways in which the data being transferred can be tampered, so though the encrypted data will not make any sense to the tamperer, what would happen if he just tampers it? How would I handle such scenarios?
What will happen if a webpage is requested by a browser which does not support SSL? Or the client accessing the website is actually some kind of malware?
I am pretty new to SSL so maybe my questions are very trivial but I don't have answers to them.
The packets including the URL itself is encrypted. Modify the bytes will make the packet invalid. As far as I know it is not accepted by the server then.
If a client browser don't support your SSL protocol it can't access the website. The client get a "Insecured Request Denied Error".
SSL is to establish a secured connection. Any software, including malware, that support the protocol can start a connection. The SSL protocol "just" encrypt the communication so the packets can't be inspected outside. So your software itself need to be protected against any attacks anyway.
The tampering will be detected on arrival and the connection automatically dropped, probably resulting in a dialog box to the browser user.
I'm not aware of any browser that doesn't support SSL. Such a thing would be singularly useless.
I am using Botan utility to perform encryption. When I initialize my connection to a remote machine using SSH, I am able to trade keys over the secure SSH connection. However, sometimes I use inetd to establish the connection, and in this case, there is no security on the inetd connection, but I need to use it to trade keys with the remote machine.
I imagine there is some standard for this whereby I send a public key over an insecure channel and the remote end uses this to encrypt a key to send back to me over the insecure channel, which I can then decrypt to get the key.
What would be an example of this kind of protocol that Botan supports?
Without previous trust, or communication through a side channel, there's no way to do that. Diffie-Hellman kex allows you to establish a channel secure against others who don't participate in the connection, but you cannot verify that you're communicating with the intended recipient.
Classic MITM example: you connect to some remote endpoint, it receives your public key and sends you something signed with that key. However, you have no way to verify whether you've sent your key to the real destination, or whether the response comes from an attacker - therefore, you have a secure tunnel, but you have no information with whom you're securely communicating (the attacker may even connect to your intended destination and proxy the traffic, which passes over him unencrypted).
To be sure that you are indeed communicating with the intended endpoint, you need to exchange some sort of identification of the host beforehand or through a secure channel. SSH does this using the "fingerprints" - it asks you on first connection if you trust that host, and you're supposed to verify the fingerprint through an independent channel.
What I did in a similar situation was to first arrange to get a private/public key pair exchanged, so, I had the public key of each client, so when they connected to me, a message was passed, that had a timestamp on it, that I could then decrypt.
If that passed, and the timestamp was valid (I used 5 seconds as the life of the timestamp) then I would exchange the key, since we had a way to securely communicate.
But, this required doing something upfront.
If you expect an anonymous user to connect and have some security that is impossible.
One article I found very helpful on issues like this was *Programming Satan's Computer", http://www.cl.cam.ac.uk/~rja14/Papers/satan.pdf, where you are trying to have a secure communication with an untrustworthy sysadmin.