LibTomNet [v0.01]

[Eric Rescorla]

tom st denis <tomstdenis at yahoo.com> writes:

> --- Eric Rescorla <ekr at rtfm.com> wrote:
> 
> > > Heck, if you could find a security flaw in LibTomNet [v0.03] I'll
> > buy
> > > you a beer.
> > Your protocol does not use appear to have any protection against
> > active attacks on message sequence, including message deletion,
> > replay, etc.  True, the attacker can't inject *predictable*
> > plaintext,
> > but he can inject garbage plaintext and have it accepted as real.
> 
> No he can't.  You need a correct HMAC for the data to be accepted. 
> This allows a replay attack which I should fix.  One beer.
> 
> Ultimately though the plaintext won't match if you replay though so its
> only half a bug [though a bug that must be fixed].
Uh, this is exactly what I said. If you delete messages or replay
them, they will pass through the HMAC and be decrypted 
(thus giving you unpredictable garbage) and passed to the
application layer.

> > Your protocol is susceptible to truncation attack via TCP FIN
> > forging.
> 
> I don't even know what that is but my protcol must read an entire block
> before parsing it.
Yes, but if I forge a TCP FIN in between blocks, you can
generate a fake connection close. This is a problem if the
protocol layered over top uses connection close to indicate
end of data as (say) HTTP does. That's why SSLv3 and above
include a close_notify message in the alerts.

> > Your server doesn't generate any random values as part of the
> > handshake,
> > thus, leaving you open to full-session replay attack.
> 
> Which is why people should use some authentication scheme ontop of
> this.  Note that the server has no clue who you are after making the
> connection.  This is intentional.\
This doesn't always help, unfortunately.

Consider the case where you're using a replayable authentication
scheme such as passwords over your encrypted session. This is
perfectly natural and people do it with SSL all the time.  So, the
attacker captures you doing some transaction replays it to the
server. Congratulations, you've now done it twice.

The standard procedure to prevent this (used in SSL, IKE, etc.) is for
the server to send the client a nonce in his hello message, thus
preventing client-side replay.

-Ekr

-- 
[Eric Rescorla                                   ekr at rtfm.com]
                http://www.rtfm.com/

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com