I mean all the bytes sent over the TCP socket (in both directions) up until
the point where the TLS layer will not send anymore data until you start
feeding it some plaintext to encrypt. You need to decide on a convention
for ordering sends relative to receives so both ends agree on the order in
which the bytes are hashed.
With OpenSSL, this would entail setting up your own intermediary BIO
between SSL/TLS and the sockets, with other libraries it may be a matter
of putting in a line of code where you get the data from the TLS library and
hand it over to the socket or vice versa.
On 11/30/2011 7:49 AM, Fred Testudo wrote:
Thanks Jakob; that's simple and elegant, and a much better fit for how
my authentic channel operates.
I'm not quite sure what you mean by the phrase 'all the "encrypted"
handshake
traffic up to a specific point'. I think it should work if I hash the
entire handshake, which I could collect using the message callback
functionality looking for handshake messages - or am I missing some
subtlety here? One end may not use OpenSSL; is there some other
reliable way to collect the appropriate data, perhaps all the raw data
stream until connection complete is indicated?
On Tue, Nov 29, 2011 at 2:59 PM, Jakob Bohm <jb-open...@wisemo.com
<mailto:jb-open...@wisemo.com>> wrote:
Here is my proposal based on experience doing something similar:
1. Establish the TLS session with a strong DH agreement, but no
certificate or an untrusted unchecked server certificate. While
establishing the TLS session, hash all the "encrypted" handshake
traffic up to a specific point with a strong hash algorithm such
as SHA256 (the attacker can see these bytes so they are not
secret).
2. On the secure channel, the client sends a short command and
gets back the servers copy of the hash, which it compares. The
client now knows the forward-secret channel is with the server
with no man-in-the-middle.
3. On the secure channel, the client sends back a short command
saying OK, all verified. The server now also knows the channel is
with the client with no man-in-the-middle.
4. The TLS session is now secure (within cryptographic limits).
On 11/29/2011 6:36 AM, Fred Testudo wrote:
I'd welcome some advice on using an existing channel as
authentication for a new connection.
The client has a narrow authenticated channel to the server; I
need to set up a normal TLS connection to the same server
authenticated by proof of having the other connection. There
is a client identifier associated with the authenticated
channel, there can be a few thousand clients. The client
should not have any built-in secret or private information,
certificates, or similar. Exchanges on the narrow channel are
visible to an eavesdropper but can't be modified; the TLS
connection will be over an open network so can be observed and
interfered with (including man-in-the-middle). I need the TLS
connection to be private and authenticated, preferably with
forward security; it needs to be "reasonably secure", the
preferred cipher is RC4_128.
The authenticated channel is very narrow and awkward to use.
Communication is by request and response initiated from the
client. The client can send about 12 bits in each request and
get 2 octets in reply, or send 5 bits and get 255 octets in
reply (and scaling in between). It would be much simpler at
the server to use just a single request, but I've not been
able to think of anything remotely secure based on so small an
exchange; it would be great if someone could come up with
something. I'd prefer to keep the number of exchanges small at
least.
I've little experience of cryptography, so I've described the
problem rather than diving immediately into my ideas for
dealing with it. I'll mention my ideas now for amusement, then
it would be great if the experts here could give me some good
ones.
My basic idea is to do a small Diffie-Hellman agreement over
the narrow channel (with pre-arranged modulus and generator),
and use the derived secret as the pre-shared key in a TLS_PSK
connection. Minimizing the exchanges on the narrow channel
would result in a weaker secret, so I need to understand how
weak it can be while still reasonably secure.
- I could make the secret be a one-time password and limit its
lifetime (say to a couple of minutes). I assume this would
allow a fairly weak secret to give reasonably secure
authentication.
- I'm not clear how the strength of the PSK affects the
strength of the encryption on the connection; if the PSK is
only 40 bits, for example, does that mean that a
TLS_PSK_WITH_RC4_128_SHA connection would only have 40 bit
security? Assuming a weak PSK weakens the encryption, could I
correct for that by using TLS_DHE_PSK to incorporate a
stronger key in the connection? I see that OpenSSL doesn't
currently implement the DHE subset of PSK; could I get an
equivalent effect by using TLS_PSK to get an authenticated
connection then immediately forcing secure renegotiation to
TLS_DH_anon?
With this sort of scheme, could a DH agreement with a 48 bit
modulus (or even smaller) give me reasonable security?
I'll be grateful for any comments, both to rip apart my ideas
if they're nonsense and to give me any pointers on how to
solve this.
Thanks,
Fred
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
