Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Freak Attack SSL/TLS Vulnerability

freakattack.com

Post reply on HN
Print view View original

101–110 of 120 posts

Re: The Freak Attack SSL/TLS Vulnerability

#101

Post by rakoo »

diafygi wrote: post #85
teekert wrote: post #84

Earlier quoted context omitted.

Hmm, as a novice, capable of setting up fine Drupal/Nginx/mail(Postfix) server I'm kind of shocked to get an F rating on ssllabs with the default, up to date, ssl enabled, Debian/Nginx config... Sounds like something to fix, not? Is there that much need for some forms of backwards compatibility? Are A+ servers badly reachable from older browsers or something? Why would the default be so bad? Somehow, in all my naivet…

Here's the how we get an A+ rating[1] for nginx on utilityapi.com: ssl on; ssl_certificate my_ssl.crt; ssl_certificate_key my_ssl.key; ssl_session_timeout 5m; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers EECDH+aRSA+AES256:EDH+aRSA+AES256:EECDH+aRSA+AES128:EDH+aRSA+AES128; ssl_session_cache shared:SSL:50m; ssl_prefer_server_ciphers on; add_header Strict-Transport-Security max-age=63072000; Our configuration doesn'…

The problem here is not "how to have a secure configuration", it's really "why is it not secure by default"; we actually need more "secure by default" because it largely reduces the chances of doing it wrong.

Re: The Freak Attack SSL/TLS Vulnerability

#102

Post by xorcist »

teekert wrote: post #95
mappu wrote: post #91

Earlier quoted context omitted.

I have an up-to-date nginx on wheezy, stock debian packages, no more than just `listen $IP ssl ; ssl_certificate ; ssl_certificate_key` directives and it gets an A on ssllabs. Do you know exactly what problem you had? It might have been unrelated to debian's presets. EDIT: a different server with a many-times-upgraded nginx package (but same version) has no `ssl_protocols` in /etc/nginx/nginx.conf and so had SSLv3 en…

These are the ones pulling down the grade: - This server is vulnerable to the POODLE attack. If possible, disable SSL 3 to mitigate. Grade capped to C. MORE INFO » - This server supports anonymous (insecure) suites (see below for details). Grade set to F. - The server supports only older protocols, but not the current best TLS 1.2. Grade capped to B. - This server accepts the RC4 cipher, which is weak. Grade capped t…

You should have a configuration file ending in .dpkg-new with whatever settings the modern nginx package provides, no need to purge and reinstall.

Re: The Freak Attack SSL/TLS Vulnerability

#103

Post by thibaut_barrere »

devinegan wrote: post #65
cpncrunch wrote: post #50

Earlier quoted context omitted.

Yep, I used it and I have no idea whatsoever whether my server is vulnerable or not. Similar for the ssllabs.com test.

If it connects to any of those ciphers with a YES, you may have a problem. They should all say NO.

thanks for clarifying this.

Re: The Freak Attack SSL/TLS Vulnerability

#104

Post by kryptiskt »

skuhn wrote: post #90
yuhong wrote: post #89

Earlier quoted context omitted.

It doesn't work either because it depends on DSA certificates.

Yep. Time to give up on anyone using a browser that depends on XP's SSL support. Much like SSLv3, they will get the message when the entire Internet stops loading in their browser.

They will get the message to randomly download some thing from the net that fixes their problem, if they're lucky it will be as well-behaved as Superfish.

Re: The Freak Attack SSL/TLS Vulnerability

#105

Post by bjornsing »

To me the whole idea of negotiating ciphers seems broken: a man-in-the-middle will always choose the weakest one.

I guess the argument is that cipher negotiation lets you implement stronger crypto without defining a new protocol version, but what is the point of that? An attacker will just negotiate for the weaker cipher anyway (unless this negotiation is cryptographically protected too of course, but this seems so complex in comparison with the rather meaningless "goal" of cipher negotiation).

Re: The Freak Attack SSL/TLS Vulnerability

#106

Post by diminoten »

diltonm wrote: post #61
geofft wrote: post #57

Earlier quoted context omitted.

What is your evidence that the vulnerability testing was done by someone supported by your tax dollars, instead of by a computer that was part of a botnet controlled by your government's cyberenemies?

Here is a check for the IP for freakattack.com: http://www.tcpiputils.com/browse/ip-address/141.212.122.194 Edit: They have been on that list for a while, so either the staff at the University is incompetent or they don't care; what was your point again?

He asked about why UMichigan is inaccessible from your network. How do you know it was a supported student activity and not either a malicious student, or a machine on the UMichigan network that's been compromised?

Have you reported the activity against your home network to UMichigan?

Re: The Freak Attack SSL/TLS Vulnerability

#107

Post by cesarb »

onyxraven wrote: post #28

Amazon already updated their ELB policies to disable RC4 https://forums.aws.amazon.com/ann.jspa?annID=2877

It's a pity that this ELB policy (ELBSecurityPolicy-2015-02) also disables 3DES. For older browsers (for instance IE8, see https://www.ssllabs.com/ssltest/viewClient.html?name=IE&vers...) the only options with a good enough key length are RC4 and 3DES.

Newer browsers also have AES, so they don't need 3DES, but it's still useful as a fallback for older clients, and it's still considered secure (but slow).

Re: The Freak Attack SSL/TLS Vulnerability

#108

Post by jvehent »

nuxi7 wrote: post #66
jvehent wrote: post #27

Earlier quoted context omitted.

Author of Server Side TLS here. Almost everyone should be able to use the intermediate configuration we propose. I recommend our conf generator at https://mozilla.github.io/server-side-tls/ssl-config-generat... . Cipherscan is also a good tool to have in your toolbox: https://github.com/jvehent/cipherscan

I'm curious why you bother with (non-EC) DHE at all? Its an interoperability nightmare thanks to the lack of DH param size negotiation in the TLS handshake and all the clients that work with the larger (larger than 1024-bit) DH params also do ECDHE. And at the end of the day, there aren't really that many DHE capable clients that won't do ECDHE. For interoperability reasons I prefer to just keep DHE off and let those…

> let those rare clients use non-PFS suites

That's not acceptable for us, which is why DHE is there. Mozilla aims to provide the best possible security to the larger number, and that drives a number of the choices in the recommended ciphers.

Re: The Freak Attack SSL/TLS Vulnerability

#109

Post by edwintorok »

jvehent wrote: post #108
nuxi7 wrote: post #66

Earlier quoted context omitted.

I'm curious why you bother with (non-EC) DHE at all? Its an interoperability nightmare thanks to the lack of DH param size negotiation in the TLS handshake and all the clients that work with the larger (larger than 1024-bit) DH params also do ECDHE. And at the end of the day, there aren't really that many DHE capable clients that won't do ECDHE. For interoperability reasons I prefer to just keep DHE off and let those…

> let those rare clients use non-PFS suites That's not acceptable for us, which is why DHE is there. Mozilla aims to provide the best possible security to the larger number, and that drives a number of the choices in the recommended ciphers.

How about the Modern suite, where you already give up compatibility with old stuff? Is non-EC DHE needed there?
Post reply on HN