9

Is it possible to send a message over https that isn't encrypted? For example, require that certificate validation and authorization occur, but not encrypt the actual data being sent over the socket?

bkritzer
  • 1,418
  • 3
  • 16
  • 27
  • I'm kindof curious how this would be used? Why not just use an alternate method of authentication? To me it seems like thats all you want, authentication of a valid.. host? *shrug* – Jakub Dec 18 '09 at 19:07
  • The question does not make sense, as https is a secure version of http running off standard port 443. The standard dictates that all encryption and certificate authorization/authentication apply to this https protocol. And anyway, any message sent over https is encrypted. Can you clarify what you are trying to do? – t0mm13b Dec 18 '09 at 19:11
  • 2
    Ah, I actually don't want to use this. I just want to make sure if I use the https protocol, I don't have to tell the server to encrypt it. This way I can trust that the data is encrypted if I use https. – bkritzer Dec 18 '09 at 19:12
  • @tommieb75 I'm also not using the standard port 443 - I'm at 7002. Does it still enforce the encryption standard in this case? – bkritzer Dec 18 '09 at 19:13
  • @bkritzer: in your case, if the https is running off port 7002 then yes the encryption is still enforced. See here on wikipedia about https protocol http://en.wikipedia.org/wiki/HTTP_Secure – t0mm13b Dec 18 '09 at 23:52

4 Answers4

23

Yes, TLS and SSL support "no-encryption" modes. Whether the particular client and server in question are configured to enable is a separate issue.

It's possible, though unlikely, that a server could enable one of these cipher suites by default. What is more likely is that a server would enable weak cipher suites (like the "export"-grade DES-based suites) by default. That's why you should carefully review the server's whitelist of cipher suites, and leave only a few trusted, widely-supported algorithms.

You can use the TLS_RSA_WITH_NULL_SHA cipher suite, among others, to protect the authenticity and integrity of traffic, without encryption.

The "RSA" in this case refers to the key exchange algorithm, while "SHA" refers to the message authentication algorithm used to protect the traffic from being altered. "NULL" is the encryption algorithm, or, in this case, the lack of encryption.

It's important to realize that the traffic, though it's not encrypted, is bundled up in SSL records. The client and server must be SSL-enabled.

If you are looking for a step-down solution where some data is exchanged over SSL, then SSL is turned off but the application traffic continues, that's possible too, but keep in mind that it offers absolutely no security for the cleartext traffic; it can be tampered with by an attacker. So, for example, authenticating with SSL, then stepping down to an "in-the-clear" protocol to receive commands that use the authentication negotiated via SSL would unsafe.

Community
  • 1
  • 1
erickson
  • 265,237
  • 58
  • 395
  • 493
  • Hello, I have some question about openssl, would you like to take a look with the following address ?. http://stackoverflow.com/questions/2542156/openssl-ssl-encryption – deddihp Mar 30 '10 at 15:48
6

The SSL/TLS specs define a "NULL cipher" which you could use for this. Most client and server software disable it for obvious reasons.

However, if you are writing your own software, you may be able to convince your library to negotiate it.

Marsh Ray
  • 2,827
  • 21
  • 20
-2

I think you can.

but it would be stupid, you will loose the point of the authentication, and leave yourself exposed to attackers that can intercept and alter your packets.

AK_
  • 7,981
  • 7
  • 46
  • 78
  • 5
    Privacy and integrity are two different things. You can use TLS without privacy; attackers could read your packets, but you'd know if they altered a packet. – erickson Aug 16 '12 at 21:37
  • @erickson I don't know SSL and it's children well enough, but why would you want to use cryptographic hash on your transit data, and not simply encrypt it? – AK_ Aug 28 '12 at 22:51
  • I haven't had an application for it myself. I was just pointing out that SSL can protect against packet alteration without providing privacy, and simple encryption is not enough to prevent packet alteration. – erickson Aug 28 '12 at 23:02
  • @erickson it's too broad of a subject to discuss here. in short, my opinion is that for integrity there is no need to use the magical powers of cryptography, nor the dark magic that is SSL. Authenticity is something else by the way, and you can get better authenticity and security, if you use the full powers of SSL. another thing, simple encryption (as long as done properly) is more then enough to defend against alteration. – AK_ Aug 30 '12 at 12:05
  • 1
    One use for TLS with authentication but not encryption would be to allow transparent caches to cache your non-private data. This would be particularly useful with videos or operating system ISO's. Also, encryption without authentication doesn't protect against alternation at all (although arguably, encryption without authentication is not "done properly"). – Brendan Long Aug 19 '15 at 23:11
-4

No, the protocol doesn't allow for that.

One solution you could do is connect over https, verify the connection, then drop subsequent connections to HTTP with a session cookie. Without that cookie, redirect back to https so that the client always connects over it.

This might not be relevant to you, though, so if you provide more information about the problem you're trying to solve we could be of more help.

McPherrinM
  • 4,526
  • 1
  • 22
  • 25