Hello,
Our "it-security" department asked me about Qualys warnings like -> SSL/TLS Compression Algorithm Information Leakage Vulnerability
As far as I learned it's compression inside ssl. postfix-2.11 knows 'tls_ssl_options = no_compression' ( see http://www.postfix.org/postconf.5.html#tls_ssl_options )
is the something comparable in dovecot too?
Looks like most extensions in ssl exist only to be disabled :-/
Thanks Andreas
Am 10.04.2014 15:04, schrieb Andreas Schulze:
Our "it-security" department asked me about Qualys warnings like -> SSL/TLS Compression Algorithm Information Leakage Vulnerability
As far as I learned it's compression inside ssl. postfix-2.11 knows 'tls_ssl_options = no_compression' ( see http://www.postfix.org/postconf.5.html#tls_ssl_options )
is the something comparable in dovecot too?
Looks like most extensions in ssl exist only to be disabled :-/
that attacks are not relevant for email because they rely on the way a webbrowser works which is not the case for a mail client - you can't trigger XSS and Ajax in a MUA
https://community.qualys.com/blogs/securitylabs/2012/09/14/crime-information...
This year, it's CRIME, a practical attack against how TLS is used in browsers. In a wider sense, the same attack conceptually applies to any encrypted protocol where the attacker controls what is being communicated
Hi,
yes its the same problem. I can confirm that it is caused by last line in base64 attachment which is longer than 72 chars in original message.
On Thu, 10 Apr 2014 16:41:38 +0200 Reindl Harald h.reindl@thelounge.net wrote:
Am 10.04.2014 15:04, schrieb Andreas Schulze:
Our "it-security" department asked me about Qualys warnings like -> SSL/TLS Compression Algorithm Information Leakage Vulnerability
As far as I learned it's compression inside ssl. postfix-2.11 knows 'tls_ssl_options = no_compression' ( see http://www.postfix.org/postconf.5.html#tls_ssl_options )
is the something comparable in dovecot too?
Looks like most extensions in ssl exist only to be disabled :-/
that attacks are not relevant for email because they rely on the way a webbrowser works which is not the case for a mail client - you can't trigger XSS and Ajax in a MUA
https://community.qualys.com/blogs/securitylabs/2012/09/14/crime-information...
This year, it's CRIME, a practical attack against how TLS is used in browsers. In a wider sense, the same attack conceptually applies to any encrypted protocol where the attacker controls what is being communicated
-- [ Ohodnotte kvalitu mailu: http://nicereply.com/websupport/Stano/ ]
Pavel Stano | Troubleshooter
http://WebSupport.sk *** BERTE A VYCHUTNAVAJTE ***
Sorry, i replied to wrong thread
On Thu, 10 Apr 2014 18:08:05 +0200 Pavel Stano stano@websupport.sk wrote:
Hi,
yes its the same problem. I can confirm that it is caused by last line in base64 attachment which is longer than 72 chars in original message.
On Thu, 10 Apr 2014 16:41:38 +0200 Reindl Harald h.reindl@thelounge.net wrote:
Am 10.04.2014 15:04, schrieb Andreas Schulze:
Our "it-security" department asked me about Qualys warnings like -> SSL/TLS Compression Algorithm Information Leakage Vulnerability
As far as I learned it's compression inside ssl. postfix-2.11 knows 'tls_ssl_options = no_compression' ( see http://www.postfix.org/postconf.5.html#tls_ssl_options )
is the something comparable in dovecot too?
Looks like most extensions in ssl exist only to be disabled :-/
that attacks are not relevant for email because they rely on the way a webbrowser works which is not the case for a mail client - you can't trigger XSS and Ajax in a MUA
https://community.qualys.com/blogs/securitylabs/2012/09/14/crime-information...
This year, it's CRIME, a practical attack against how TLS is used in browsers. In a wider sense, the same attack conceptually applies to any encrypted protocol where the attacker controls what is being communicated
-- [ Ohodnotte kvalitu mailu: http://nicereply.com/websupport/Stano/ ]
Pavel Stano | Troubleshooter
http://WebSupport.sk *** BERTE A VYCHUTNAVAJTE ***
Reindl Harald:
that attacks are not relevant for email because they rely on the way a webbrowser works which is not the case for a mail client - you can't trigger XSS and Ajax in a MUA
sure, that may be right, but
We manage numerous public available services. And every time we go through our
Qualys reports I have to explain this message from Qualys as not
relevant/harmless/cannot change.
It takes time to describe this fact again and again to our it-security people.
And there are many other people in the same situation like me... That's my main intention to ask how to disable ssl compression in dovecot.
Andreas
Am 23.04.2014 23:52, schrieb Andreas Schulze:
Reindl Harald:
that attacks are not relevant for email because they rely on the way a webbrowser works which is not the case for a mail client - you can't trigger XSS and Ajax in a MUA
sure, that may be right, but
We manage numerous public available services. And every time we go through our Qualys reports
https://www.ssllabs.com/ssltest/ just don't alow anything other than https and port 443 - what reports are you speaking about?
I have to explain this message from Qualys as not relevant/harmless/cannot change
so what - which fools are allowed to audit you while have no clue what they are talking about?
Reindl Harald:
https://www.ssllabs.com/ssltest/ just don't alow anything other than https and port 443 - what reports are you speaking about? your free to configure pop3s/imaps/ssmtp on the "nonstandard" port 443
I have to explain this message from Qualys as not relevant/harmless/cannot change
so what - which fools are allowed to audit you while have no clue what they are talking about? Qualys, they have more services than ssllabs.com
see andreasschulze.de/tmp/qualys-id-38599.jpg
Andreas
Andreas Schulze wrote:
Reindl Harald:
https://www.ssllabs.com/ssltest/ just don't alow anything other than https and port 443 - what reports are you speaking about? your free to configure pop3s/imaps/ssmtp on the "nonstandard" port 443
I have to explain this message from Qualys as not relevant/harmless/cannot change
so what - which fools are allowed to audit you while have no clue what they are talking about? Qualys, they have more services than ssllabs.com
see andreasschulze.de/tmp/qualys-id-38599.jpg
Andreas
Well they seem to know what they are talking about. The description of the threat in linked screenshot says "attacker needs to have ability to submit any plain text"
The more interesting question is why do you need to explain to your it-security people that compression in POP3 is not vulnerable to this attack. I mean if they're in charge of security, the really should know that.
Benny Pedersen skrev den 2014-04-24 17:56:
Andreas Schulze skrev den 2014-04-24 13:04:
Jiri Bourek:
The more interesting question is why do you need to explain to your
it-security people I'm asking that myself too :-/atleast dovecot stopped breaking dkim now :)
or no:
Authentication-Results: duggi.junc.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=junc.eu header.i=@junc.eu header.b=DnJ5TUMC; dkim-atps=neutral
works for some just not all :(
Authentication-Results: duggi.junc.org; dkim=pass (4096-bit key) header.d=andreasschulze.de header.i=@andreasschulze.de header.b=lQJpd3+d; dkim-atps=neutral
both is mails on dovecot maillist recieved today
Jiri Bourek:
Well they seem to know what they are talking about. The description of the threat in linked screenshot says "attacker needs to have ability to submit any plain text"
I wrote the attached patch to add SSL_OP_NO_COMPRESSION to dovecot. Looks not perfect but definitly works.
Andreas
On 20.5.2014, at 22.49, Andreas Schulze sca@andreasschulze.de wrote:
Jiri Bourek:
Well they seem to know what they are talking about. The description of the threat in linked screenshot says "attacker needs to have ability to submit any plain text"
I wrote the attached patch to add SSL_OP_NO_COMPRESSION to dovecot. Looks not perfect but definitly works.
Added a Postfix-like ssl_options setting: http://hg.dovecot.org/dovecot-2.2/rev/cea292767b95
But now I'm wondering if no-compression should be enabled by default?..
On 3.7.2014 23:55, A. Schulze wrote:
Timo Sirainen:
But now I'm wondering if no-compression should be enabled by default?..
to not potential break something I would not change the default now but maybe later...
Thanks! Andreas
Not sure if it's upstream change, but Debian disabled compression in openssl by default in June (http://metadata.ftp-master.debian.org/changelogs//main/o/openssl/openssl_1.0...)
As I understand it, any program using the library has compression turned off by default.
participants (7)
-
A. Schulze
-
Andreas Schulze
-
Benny Pedersen
-
Jiri Bourek
-
Pavel Stano
-
Reindl Harald
-
Timo Sirainen