Using HTTPS in Java Without Encryption

Question

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

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 2

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.