[Top] [All Lists]

Re: [ietf-smtp] When using TLS, would randomizing the order of the EHLO response be helpful?

2013-03-21 04:10:58
On 21/03/2013 07:47, Carl S. Gutekunst wrote:
On every SMTP server in the world, the first 100 to 250 bytes send by the server after TLS negotiation completes are both constant and known: they're the EHLO response. So that got me wondering if randomizing the EHLO response could be helpful in mitigating statistical attacks. Obviously the degree of "randomizing" is limited; RFC 5321 requires the first line to be the FQDN of the receiver, and every line will contain "\r\n\220-". The most I can do is randomize whole lines. But I don't have an intuitive feel for what might be effective in disrupting these statistical code-breaking techniques; hence the question.
Isn't it '250-'?

Anyway, I'm not a cryptographer either, but my limited understanding suggests that things like TLS work on a 'block' of data at once, not byte-by-byte. So, if this is deemed a risk or potential risk, it would make sense to make the first 'block' as random as possible. AIUI TLS uses the previous block as part if the encryption for the next block, so if they can't tell what the first block contains, they can't do the rest of the stream either.

So, randomising line order, possibly adding 'x-messwithhackers: <random string>' pseudo-capabilities, adding random text after the FQDN of the receiver on the first line of the EHLO response, etc, would all stand a fair chance of making it harder to hack.

But, I'm not a cryptographer, so I may be talking total garbage :-)


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53
ietf-smtp mailing list