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> wrote:
> On Sat, Sep 13, 2014 at 9:05 PM, Hilton Gibson <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
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
