On Jun20, 2012, at 18:42 , Magnus Hagander wrote:
> That is a very good point. Before we design *another* feature that
> relies on it, we should verify if the syntax is compatible in the
> other libraries that would be interesting (gnutls and NSS primarily),
> and if it's not that at least the *functionality* exists ina
> compatible way. So we don't put ourselves in a position where we can't
> proceed.
Hm, here's another problem with relying on SSL/TLS for compression.
RFC2246, which defines TLS 1.0, explicitly states that
"TLS_NULL_WITH_NULL_NULL is specified and is the initial state of a
TLS connection during the first handshake on that channel, but MUST
NOT be negotiated, as it provides no more protection than an
unsecured connection." [RFC2246, A.5. The Cipher Suite]
and that paragraph is still present in RFC5246 (TLS 1.2). The other
cipher suits without actual encryption seem to be
TLS_RSA_WITH_NULL_MD5
TLS_RSA_WITH_NULL_SHA
TLS_RSA_WITH_NULL_SHA256 (TLS 1.2)
Unless I'm missing something, that leaves us with no way of skipping the
initial RSA handshake and also (more importantly) of computing a MD5
or SHA digest of every packet sent.
I'm starting to think that relying on SSL/TLS for compression of
unencrypted connections might not be such a good idea after all. We'd
be using the protocol in a way it quite clearly never was intended to
be used...
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
