Hi,

I have a server which advertises STARTTLS and accepts TLS if the
client wishes or accepts in-the-clear otherwise. I need to be able to
disallow negotiation of weak (56 bit or below) encryption without
enforcing a TLS requirement (in-the-clear should still be fine).

Appreciate any info as the FAQ recommends this group for advanced
TLS info.

In article <1190908263.687683.24990 [at] w3g2000hsg.googlegroups.com>
decourl [at] gmail.com writes:
>
> I have a server which advertises STARTTLS and accepts TLS if the
>client wishes or accepts in-the-clear otherwise. I need to be able to
>disallow negotiation of weak (56 bit or below) encryption without
>enforcing a TLS requirement (in-the-clear should still be fine).

Hm, I think it would help if you tried to elaborate on what you're
trying to achieve and why, because as stated, that requirement sounds
pretty bizarre...:-) If you're just trying to help "good" users to not
inadvertenly use a weak cipher, I'd say don't bother, since these days
they'd probably have to work hard to end up using anything below 128-bit
RC4.

--Per Hedeland
per [at] hedeland.org

<decourl [at] gmail.com> wrote:

> Hi,
>
> I have a server which advertises STARTTLS and accepts TLS if the
> client wishes or accepts in-the-clear otherwise. I need to be able to
> disallow negotiation of weak (56 bit or below) encryption without
> enforcing a TLS requirement (in-the-clear should still be fine).
>
> Appreciate any info as the FAQ recommends this group for advanced
> TLS info.

I'd go with Per, you have a strange requirement.

By default, most use the best encryption available. Does your log really
list 56 bit encryption entries?

If a client can only use 56 bit encryption, I doubt he will fail back
nicely to no starttls if you disable low grade encryption. You'll
probably have to add "Srv_Features:computername S" entries to the access
file to disable STARTTLS for certain clients.

Looking at the code, if you recompile sendmail with -D_FFR_TLS_1, you
will be able to add an "O CipherList=HIGH" options to your sendmail.cf
file to select the encryptions methods availble to the TLS engine. (See
the openssl ciphers manual page for how to write the CipherList=
string.)

I have not tested this. FFR means For Future Release. Or experimental.
Or "you're on your own".

This page explains it with siteconfig and m4 cf exemples (the proper way
to do things):
http://sial.org/howto/sendmail/cipherlist/

In article <1i54nze.1qsyacc7a4xusN%hugo [at] EINTR.net> hugo [at] EINTR.net (Hugo
Villeneuve) writes:
><decourl [at] gmail.com> wrote:
>
>> Hi,
>>
>> I have a server which advertises STARTTLS and accepts TLS if the
>> client wishes or accepts in-the-clear otherwise. I need to be able to
>> disallow negotiation of weak (56 bit or below) encryption without
>> enforcing a TLS requirement (in-the-clear should still be fine).
>>
>> Appreciate any info as the FAQ recommends this group for advanced
>> TLS info.
>
>I'd go with Per, you have a strange requirement.
>
>By default, most use the best encryption available. Does your log really
>list 56 bit encryption entries?
>
>If a client can only use 56 bit encryption, I doubt he will fail back
>nicely to no starttls if you disable low grade encryption. You'll
>probably have to add "Srv_Features:computername S" entries to the access
>file to disable STARTTLS for certain clients.
>
>Looking at the code, if you recompile sendmail with -D_FFR_TLS_1, you
>will be able to add an "O CipherList=HIGH" options to your sendmail.cf
>file to select the encryptions methods availble to the TLS engine. (See
>the openssl ciphers manual page for how to write the CipherList=
>string.)

Well, while we're giving out solutions without understanding the
problem:-), it can also be worth pointing to the STARTTLS section in
cf/README, where you at least in principle can figure out that you can
suppply an extension to the tls_client ruleset via LOCAL_TLS_CLIENT, and
therein require that $&{cipher_bits} is 0 or unset or > 56. This could
at least be used to give a meningful error message, that just might be
displayed by the MUA - you're very unlikely to get that if the SSL
handshake fails due to disjunct cipher lists.

>I have not tested this. FFR means For Future Release. Or experimental.
>Or "you're on your own".

I haven't looked at that code (nor tried it), but this should be safer
than most FFRs, since it's very trivial - sendmail just needs to pass
the CipherList string as-is to OpenSSL. (Though admittedly there are
many mistakes that can be made in OpenSSL usage.:-)

>This page explains it with siteconfig and m4 cf exemples (the proper way
>to do things):
>http://sial.org/howto/sendmail/cipherlist/

Hm, I would hardly call RC4-MD5 "weak" though, especially not in this
context. Connect to your bank with your DES3- and AES-capable browser
and check what you get...:-)

--Per Hedeland
per [at] hedeland.org