Hello, internals!
I've created a new RFC to discuss improving default TLS encryption settings:
https://wiki.php.net/rfc/improved-tls-defaults
This RFC complements the previously accepted TLS Peer Verification RFC.
I've proposed these (relatively straight-forward) changes in RFC form
because there does exist the potential for minimal BC breakage. I see this
breakage as a good thing because it enhances security, however everyone may
not share this view.
Thanks in advance for your participation.
Hey Daniel
-----Original Message-----
From: Daniel Lowrey [mailto:rdlowrey@gmail.com]
Sent: Tuesday, January 28, 2014 10:51 PM
To: internals@lists.php.net
Subject: [PHP-DEV] [RFC] Improved TLS DefaultsHello, internals!
I've created a new RFC to discuss improving default TLS encryption settings:
https://wiki.php.net/rfc/improved-tls-defaults
This RFC complements the previously accepted TLS Peer Verification RFC.
I've proposed these (relatively straight-forward) changes in RFC form
because there does exist the potential for minimal BC breakage. I see this
breakage as a good thing because it enhances security, however everyone may
not share this view.Thanks in advance for your participation.
I am not a security expert but I read (somewhere, don't ask me where please) that further ciphers should be excluded.
Maybe they are already covered in !LOW but just in case:
!DES:!3DES:!EXP:!SRP:!PSK
Cheers,
Robert
Great! The default cipher list is really the main thing I want to flesh out
during the discussion process. You also won't hear me claim to be an
"expert" (whatever that entails).
I think having the community as a whole decide what's right for PHP is the
best course of action here. Any feedback on these points is appreciated
(especially feedback that comes with concrete references).
Hey Daniel
-----Original Message-----
From: Daniel Lowrey [mailto:rdlowrey@gmail.com]
Sent: Tuesday, January 28, 2014 10:51 PM
To: internals@lists.php.net
Subject: [PHP-DEV] [RFC] Improved TLS DefaultsHello, internals!
I've created a new RFC to discuss improving default TLS encryption
settings:https://wiki.php.net/rfc/improved-tls-defaults
This RFC complements the previously accepted TLS Peer Verification RFC.
I've proposed these (relatively straight-forward) changes in RFC form
because there does exist the potential for minimal BC breakage. I see
this
breakage as a good thing because it enhances security, however everyone
may
not share this view.Thanks in advance for your participation.
I am not a security expert but I read (somewhere, don't ask me where
please) that further ciphers should be excluded.
Maybe they are already covered in !LOW but just in case:!DES:!3DES:!EXP:!SRP:!PSK
Cheers,
Robert
Cheers,
Robert
Also: apologies for the previous top-post ... gmail makes it easy to forget.
Hi Daniel,
I've created a new RFC to discuss improving default TLS encryption
settings:https://wiki.php.net/rfc/improved-tls-defaults
This RFC complements the previously accepted TLS Peer Verification RFC.
I've proposed these (relatively straight-forward) changes in RFC form
because there does exist the potential for minimal BC breakage. I see this
breakage as a good thing because it enhances security, however everyone may
not share this view.
I haven't read the RFC carefully yet, but it's great proposal!
You probably reviewed this page already.
https://wiki.mozilla.org/Security/Server_Side_TLS
Quoting from the page
The general purpose ciphersuite at the time of this writing is:
ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-RC4-SHA:AES128:AES256:RC4-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:!PSK
Is your recommendation from OpenSSL project or else?
I couldn't find a page with quick search.
@STRENGTH
Additionally the cipher string @STRENGTH can be used at any point to sort
the current cipher list in order of encryption algorithm key length.
https://www.openssl.org/docs/apps/ciphers.html
@STRENGTH orders cipher as mozilla recommend? It seems this option is for
this and/or similar purpose.
Slight differences do not matter much so having @STRENGH is secure and
easier to maintain, probably.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
I haven't read the RFC carefully yet, but it's great proposal!
Thanks!
You probably reviewed this page already.
https://wiki.mozilla.org/Security/Server_Side_TLS
Yes I have! The cipher list proposed in the RFC was gathered from disparate
research sources that did not include the Mozilla site. However you'll see
that the excluded ciphers in the RFC actually match up directly with those
in Mozilla's "Mandatory discards" section.
Is your recommendation from OpenSSL project or else?
I couldn't find a page with quick search.
This is not surprising: the OpenSSL documentation is fairly outdated in
most areas. However, I've made an effort to provide references for my
reasoning with regard to the individual ciphers listed in the RFC. In
response to your question, I've added more links (including references to
the relevant Mozilla project page) and updated some of the relevant
information in the RFC text. These changes are marked in the revision
history at the top of the wiki page and I've incremented the RFC's version
number from v0.1 to v0.2 to reflect the updates.
@STRENGTH orders cipher as mozilla recommend? It seems this option is for
this and/or similar purpose.
The @STRENGTH element simply allows us to prefer algorithms with longer key
lengths (e.g.256-bit ciphers preferred to 168-bit preferred to 128-bit).
Because TLS clients will negotiate the cipher according to their preference
order it's sensible to add this annotation. The exception to this rule is
when a server specifies the "Honor Cipher Order" option (also proposed for
addition as part of the RFC). For these cases the @STRENGTH specification
still applies because as servers we still should prefer stronger ciphers by
default.
Hi Daniel,
For those not overly familiar with attacks, here's a couple of references
for consideration:
http://news.netcraft.com/archives/2013/06/25/ssl-intercepted-today-decrypted-tomorrow.html
http://www.isg.rhul.ac.uk/tls/Lucky13.html (related to previous padded
oracle attack)
The Mozilla defaults are geared towards achieving perfect forward security
where possible (looks like IE and Safari have a way to go!) and it's
becoming more prominent with the NSA's activities.
The RFC, at a minimum, seems a positive change.
Paddy
--
Pádraic Brady
http://blog.astrumfutura.com
http://phpsecurity.readthedocs.org http://www.survivethedeepend.com/
Zend Framework Community Review Team
Zend Framework PHP-FIG Representative