Using HTTPS in Java Without Encryption

Question

Hi,

We're looking for a solution that will allow us to use HTTPS without encryption. Why? Here's the story:

Our product (installed at customers) connects to our servers to fetch updates, post information, etc. We want the product to verify that it is connected to the server (and not an imposter) prior to posting data. We also need to ensure there are no man-in-the-middle attacks (that is, the content should be signed, etc.). However, our customers require that they can sniff the traffic (Wireshark, tcpdump, etc.) and view the entire transaction's contents. This is for compliance and security reasons.

Our product is written in Java, by the way.

Any ideas?

UPDATE: Please excuse me if I'm not using the correct form for responding to answers, I'm fairly new on this site.

First of all, thank you for your quick answers!

Our reason for investigating the possibility of HTTPS is because we don't want to invent a new protocol here. It's not just the amount of work but also the fact that inventing your own security protocol (even if just for signing) is generally considered bad practice. We're trying to gain HTTPS's advantages in authenticating the server (which is important, this server also serves executable code which can be quite large - we don't want anyone serving malware or DoSing our customers with large data that only after receiving the entire thing will the system find out it's bad) as well as ensuring MITM doesn't occur (the signing of the messages themselves). We don't mind if anyone evesdropes on the traffic because it never contains something considered confidential. Furthermore, it doesn't necessarily need to be easy to read the contents in Wireshark, only possible so auditors can do it.

@Nate Zaugg - no, this is not a joke. It's actually surprising that vendors use HTTPS with encryption today and don't get a lot of backlash from customers with strict compliance issues.

@erickson - The first solution with the NULL cipher suits looks interesting, we'll look into it. The second solution will require a set of keys for each customer - not something we'd like to manage.

@ZZ Coder - do you mean that with null ciphers it will not be possible to view the contents in Wireshark?

Answer 1

If you only need signing, why can't you just sign each response with a private key (putting the signature in a header) and verify it with a public key on the client, but not use HTTPS at all? So long as your private key remains secret and you choose an appropriate signature algorithm, this should prevent tampering with the body of the response but without keeping that body secret.

Answer 2

There are SSL "ciphersuites" without encryption, and all versions of the Sun JSSE provider support SSL_RSA_WITH_NULL_SHA. However, all of the application data is still wrapped in SSL records (to carry the MAC that provides integrity protection, etc.), so as you look at it in Wireshark, you'll see these structures.

Alternatively, as long as you don't use ephemeral Diffie-Hellman (one of the DHE_XXX ciphersuites), you can give Wireshark the server's private key, and it will decrypt an SSL session. While this is some extra work, it doesn't impose any unusual requirement on the server or client to support the seldom-used unencrypted ciphersuites.

Answer 3

You can try to use the NULL ciphers (1 and 2) but most servers are configured not to accept the weak ciphers. Of course, these 2 ciphers are the weakest.

Even the payload will be in clear text, it's still wrapped inside SSL frame so most common packet decipher doesn't work.

Answer 4

I would agree with @Jon Skeet - you shouldn't be trying to use a crippled HTTPS, instead you should just sign your responses. You can look at some of the documentation for Amazon's S3 for a good example of a sturdy, robust, and yet fairly straightforward security model.

In short though, the basic idea is, have some kind of secret key, append it and a timestamp to your message and hash that. Send the hash and date (but not the secret, obviously) along with your message to the server. Your server then checks that the date is close enough to trust (say 15 minutes) and hashes the request, date, and the secret key which it has on file. If it gets the same hash, then a trusted resource generated the request, and the server can safely proceed.

Obviously, this is not safe from man-in-the-middle sniffing (which you seem to be ok with) but it will prevent a MITM from changing or creating phony requests.

Answer 5

well shouldn't each client have a distinct key anyway? otherwise how does your server know who is posting? the server doesn't care any man in the middle?

if each client has a key, like a simple password, that the server knows, the key can be used as salt with a hash function to sign requests/responses.