I use a verifier to check my config:

https://www.ssllabs.com/ssltest/analyze.html?d=exams.victoria.ac.nz

Note that my settings are less secure than I might like, because increasing 
them causes some platforms (especially mobile platforms) to fail to access the 
content, while leaving nothing useful in the logs.

Personally I find the Mozilla advice a little strong on the "force users with 
outdated browsers to update" approach.

It's  also possible to force users who login to use more secure credentials 
than those who just access content, if you can assume that only admin staff 
login from their desktops with recent browsers. There's an example on 
https://httpd.apache.org/docs/2.0/ssl/ssl_howto.html

Cheers
stuart


From: Alan Orth [mailto:alan.o...@gmail.com]
Sent: Sunday, 14 September 2014 7:39 p.m.
To: Ivan Masár
Cc: dspace-tech@lists.sourceforge.net
Subject: Re: [Dspace-tech] Recommended TLS cipher suite for sites using HTTPS

Hi, Hilton.

Thanks for your reply.  First, I'd like to point out that I reverse proxy 
DSpace via nginx (and Apache httpd a few years ago).  The decision to put nginx 
/ httpd in front of Tomcat was made partially on the fact that it's easier to 
configure HTTPS in those servers than Tomcat, and nginx supports more modern 
crypto than Apache http or Apache Tomcat.  Also mod_rewrite and vhosts etc were 
easier.

Your HTTPS configuration could use several improvements.  Attached is a 
screenshot of the negotiated cipher suite as seen in Chrome in GNU/Linux.  Of 
note:
- The connection is encrypted using AES CBC.  AES is government-grade security, 
but implemented in CBC mode it is vulnerable to padding oracle attacks (see 
BEAST and Lucky13)[0].  It is recommended to use GCM mode (galois counter mode).
- Message authentication (MAC, basically a hash or fingerprint) is using SHA1, 
which is of course very old and started showing weaknesses in academic circles 
and was first shown to be broken in 2005[1].
- Your connection is using Diffie-Hellman Ephemeral, which is good! Ephemeral 
means that there is a temporary secret used in the HTTPS negotiation that is 
thrown away after the session. In the scenario that an adversary (NSA?) gets 
your HTTPS key and records secure traffic, they won't be able to decode those 
sessions.  This is called 'forward secrecy' (sometimes "perfect" forward 
secrecy).

Other than that, your HTTPS certs are signed using SHA1, which has been 
deprecated by all major browsers in favor of SHA2[2].

It's kinda overwhelming, but using the Mozilla cipher list will get you 
started.  They are a list of safe defaults which take into account most of the 
latest information we have on cryptography.

Hope that helps,

[0] https://wiki.mozilla.org/Security/Server_Side_TLS#Attacks_on_TLS
[1] https://www.schneier.com/blog/archives/2005/02/sha1_broken.html
[2] https://shaaaaaaaaaaaaa.com/

On Sat, Sep 13, 2014 at 10:35 PM, helix84 
<heli...@centrum.sk<mailto:heli...@centrum.sk>> wrote:
On Sat, Sep 13, 2014 at 9:05 PM, Hilton Gibson 
<hilton.gib...@gmail.com<mailto:hilton.gib...@gmail.com>> wrote:
> Who is the arbiter "safe ciphers"?
> I am not a cipher expert.

There's no arbiter. The set changes over time as new vulnerabilities
are found in existing ciphers and new ciphers are developed to
mitigate those attack vectors. A cipher might look good on paper, but
only widespread use reveals its weaknesses. Then there is the natural
deprecation of shorter key sizes, which is required as new computers
gets faster. Furthermore, errors exist in PRNGs, which encryption
vitally depends on. The only way is to keep up to date on this
information. That's why the Mozilla list Alan mentioned helps - they
watch it for you and give you their recommendations.


Regards,
~~helix84

Compulsory reading: DSpace Mailing List Etiquette
https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette



--
Alan Orth
alan.o...@gmail.com<mailto:alan.o...@gmail.com>
http://alaninkenya.org
http://mjanja.co.ke
"In heaven all the interesting people are missing." -Friedrich Nietzsche
GPG public key ID: 0x8cb0d0acb5cd81ec209c6cdfbd1a0e09c2f836c0
------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech
List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette

Reply via email to