Keep Server Online
If you find the Apache Lounge, the downloads and overall help useful, please express your satisfaction with a donation.
or
A donation makes a contribution towards the costs, the time and effort that's going in this site and building.
Thank You! Steffen
Your donations will help to keep this site alive and well, and continuing building binaries. Apache Lounge is not sponsored.
| |
|
 Topic: Logjam, SSL Labs grading changes, and more |
|
| Author |
|
Steffen
Moderator
Joined: 15 Oct 2005
Posts: 3092
Location: Hilversum, NL, EU
|
 Posted: Fri 22 May '15 10:04 Post subject: Logjam, SSL Labs grading changes, and more |
 |
|
Got this from Ivan's Bulletproof TLS Newsletter:
Dear Steffen Land,
Welcome to another edition of Bulletproof TLS Newsletter, which brings
you fresh and relevant information about SSL/TLS and Internet PKI.
In this issue:
1. Logjam
2. SSL Labs grading changes in v1.17
3. Chrome and SHA1
4. PCI DSS v3.1
5. Public Key Pinning Extension for HTTP
------------------------------------------------------------------------
Logjam
Logjam [1] is a newly-disclosed man-in-the-middle (MITM) attack that
exploits a TLS protocol weakness, but works only against servers that
use insecure Diffie-Hellman key exchange. To execute an attack, the
MITM intercepts a client connection, then connects to the server,
obtains and breaks weak DH parameters, and uses them to finalize the
connection with the client. The attack is successful because the weak
DH parameters are signed by the server’s strong key, allowing the MITM
to impersonate the server. Conceptually, the attack is similar to the
FREAK attack disclosed earlier this year [2].
If you’ve been following best configuration practices, Logjam doesn’t
affect you. Only misconfigured servers that support DH parameters below
1024 bits are affected. If you are affected, the solution is to
increase the strength of DH parameters to at least 1024 bits, but
ideally 2048 (read on for more information). What if you can’t, for
example if you’re using some older platform? One possible solution
would be to put that old server behind a more secure proxy.
Another aspect that came out of the same research paper is that many
server platforms use weak (1024-bit) DH parameters with common primes.
Due to the way DH works, a powerful adversary (e.g., a nation state)
could invest a lot of resources in breaking those common primes,
allowing them to passively monitor all connections that involve them.
Because this attack is passive (the attacker doesn’t influence TLS
negotiations), the danger exists only if weak DH parameters are
actively used with clients. Thus, for best results, upgrade to
2048-bit DH parameters. If you can’t do that straight away, you should
at least try to configure your servers to use custom-generated
parameters. In any case, you should be preferring the faster ECDHE key
exchange with modern clients.
Logjam highlighted the fact that modern clients continue to accept
insecure DH parameters. Microsoft recently changed that to enforce
1024 bits as the minimum strength. Chrome and Firefox will do the same
in the near future, while Apple is planning to stay with 768 bits. As
always, the issue is compatibility with older (misconfigured) servers
on the Internet.
[1] The Logjam Attack
https://weakdh.org
[2] Tracking the FREAK Attack
https://freakattack.com
------------------------------------------------------------------------
SSL Labs grading changes in v1.17
SSL Labs [1] recently released version 1.17.10, which came with some
interesting grading changes. First of all, RC4 usage with TLS 1.1+ is
now discouraged with a C. Servers that support RC4 in any capacity
(i.e., with older clients and protocols) have their score capped at B.
Lack of support for TLS 1.2 is now penalised more heavily, also with a
C. Finally, servers that use weak DH parameters below 2048 bits are
capped at B. There is no change in the treatment of insecure DH
parameters (below 1024 bits); they had been resulting in F even before
Logjam.
[1] SSL Labs
https://www.ssllabs.com
------------------------------------------------------------------------
Chrome and SHA1
I wrote to you before about Chrome’s plans for SHA1 deprecation. They
had a plan for multi-step process, but, with the release of Chrome 42
in April, that process is now complete. Today, if your SHA1
certificate expires during 2016, you get a warning; if it expires in
2017 and later, you get an error.
However, what’s not immediately obvious is that you can receive a
warning or an error even if you’re serving a full SHA2 certificate
chain. This is because Chrome doesn’t have full control of certificate
chain construction; even when sites serve correct chains, client TLS
stacks might decide to use different chains and submit them to Chrome.
It’s not clear how many sites are affected, but I’ve heard from users
of both SSL Labs and Feisty Duck web sites, complaining about seeing
errors in Chrome. Apparently, the root cause is that some of these
alternative certificate chains rely on SHA1 intermediates and cause
warnings.
[1] Gradually sunsetting SHA-1
http://googleonlinesecurity.blogspot.co.uk/2014/09/gradually-sunsetting-sha-1.html
------------------------------------------------------------------------
PCI DSS v3.1
In April, the PCI Security Standards Council released the v3.1
revision of the PCI DSS standard, effectively making SSL v3 and TLS
v1.0 obsolete. New deployments are not required to rely on this older
protocols. Existing deployments should start migrating straight away
and have until 30 June 2016 to complete the process. As a special
exception, SSL v3 can remain in use on platforms that can’t be
attacked using the POODLE attack (which requires client-side
JavaScript execution), for example POS terminals.
[1] PCI COUNCIL PUBLISHES REVISION TO PCI DATA SECURITY STANDARD
https://www.pcisecuritystandards.org/pdfs/15_04_15%20PCI%20DSS%203%201%20Press%20Release.pdf
------------------------------------------------------------------------
Public Key Pinning Extension for HTTP
Public key pinning is a powerful security technique that allows web
sites to overcome the biggest weakness of Internet PKI, which is the
fact that any CA can issue a certificate for any site. With pinning,
sites can establish and enforce their own cryptographic integrities,
restricting which certificates work for them. Now, finally, there is
a standard for public key pinning in RFC 7469 [1]. At this time,
Chrome and Firefox have near-complete support for this new standard.
[1] Public Key Pinning Extension for HTTP
http://tools.ietf.org/html/rfc7469 |
|
| Back to top |
|
James Blond
Moderator
Joined: 19 Jan 2006
Posts: 7371
Location: Germany, Next to Hamburg
|
|
| Back to top |
|
|
|
|
|
|
