Re: [Dspace-tech] Recommended TLS cipher suite for sites using HTTPS
Well, it seems to me that there are two things we are protecting here: 1. The privacy of users' reading habits. This is likely of interest only to governments, whose powers of stealth and coercion are so vast that they wouldn't bother with trying to break our encryption. 2. Users' logon credentials. Given the depressing statistics on how many people use the same password for everything, this would be of interest to medium-scale criminal enterprises, who probably *would* find it worthwhile to attack weaker crypto. So I would say that a public repository should nevertheless employ reasonably strong crypto. We need to balance security against accessibility, and our threat model is different from that facing a payment card system or a military C3I network or an industrial control system. -- Mark H. Wood Lead Technology Analyst University Library Indiana University - Purdue University Indianapolis 755 W. Michigan Street Indianapolis, IN 46202 317-274-0749 www.ulib.iupui.edu signature.asc Description: Digital signature -- 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
Re: [Dspace-tech] Recommended TLS cipher suite for sites using HTTPS
>I think you're missing the point. Protecting the content is as you say >unimportant if it's open content. But the big threat here is to the privacy of >the patrons. Your viewing history, if it gets into the wrong hands, could >easily put you or someone you care about at risk. The big threat for me is that someone can unload a bogus thesis into my repository and on that basis claim to have a degree ... When a TLS connection gets established, the two parties negotiate the most secure option they both support. That negotiation is driven by the client, meaning that modern sanely configured clients will normally be very secure from passive listening attacks. Active attacks are more challenging to prevent, and raising the minimum security of the certs supported is one approach to do that. Cheers stuart -- 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
Re: [Dspace-tech] Recommended TLS cipher suite for sites using HTTPS
I think you're missing the point. Protecting the content is as you say unimportant if it's open content. But the big threat here is to the privacy of the patrons. Your viewing history, if it gets into the wrong hands, could easily put you or someone you care about at risk. Perhaps there's a way to get a secure channel for those who are able to make use of it, and drop down to less secure ciphers for your IE6 users? I don't know TLS well enough to know the answer, or even to know whether this is a good idea. Best Jonathan On Sep 15, 2014, at 4:28 PM, Stuart Yeates wrote: > Both of the guidelines make complete sense if you’re a bank (or the payroll > system of a university). They make less sense when if you are a service whose > reason for existence is to promulgate information. For repositories to > enforce the latest and greatest security settings for users to access > documents makes no sense and is insane if (like my repositories) we also > offer the same documents over HTTP. > > Note, for example, that your site can’t be accessed from IE 6 or by bots > running certain varieties of Java. That’s probably not a bad choice unless > you need it to be accessible to the third world, which has a much older > technological profile than the west. > > It may make sense to lock down submission / admin interfaces, particularly if > these are accessed from off campus. > > Cheers > stuart > > From: Alan Orth [mailto:alan.o...@gmail.com] > Sent: Monday, 15 September 2014 8:36 p.m. > To: Stuart Yeates; Ivan Masár > Cc: dspace-tech@lists.sourceforge.net > Subject: Re: [Dspace-tech] Recommended TLS cipher suite for sites using HTTPS > > Stuart, > > Interesting that you consider Mozilla's guidlines too strict. > Bettercrypto.org's are even more so. :) > > For reference, I use a "stricter" config than Mozilla's in that I disallow > SSLv3 (as even XP supports TLS 1.0), and I get an A+ on the Qualys SSL test: > > https://www.ssllabs.com/ssltest/analyze.html?d=cgspace.cgiar.org > > TLS is fun, isn't it?! > > Alan > > On 09/15/2014 01:20 AM, Stuart Yeates wrote: > 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 > onhttps://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 cert
Re: [Dspace-tech] Recommended TLS cipher suite for sites using HTTPS
There is also an argument that ‘freedom to read’-type statements suggest HTTPS to prevent casual snooping on people’s reading habits, however this is undermined by our use of DOI and handle which are reliably HTTPS, so we’re already leaking that info. Cheers stuart From: Hilton Gibson [mailto:hilton.gib...@gmail.com] Sent: Tuesday, 16 September 2014 8:34 a.m. To: Stuart Yeates Cc: Alan Orth; Ivan Masár; dspace-tech@lists.sourceforge.net Subject: Re: [Dspace-tech] Recommended TLS cipher suite for sites using HTTPS +1 to Stuart, my only intention with https is to secure user credentials, beyond that it does not matter. Hilton Gibson Ubuntu Linux Systems Administrator JS Gericke Library Room 1025C Stellenbosch University Private Bag X5036 Stellenbosch 7599 South Africa Tel: +27 21 808 4100 | Cell: +27 84 646 4758 On 15 September 2014 22:28, Stuart Yeates mailto:stuart.yea...@vuw.ac.nz>> wrote: Both of the guidelines make complete sense if you’re a bank (or the payroll system of a university). They make less sense when if you are a service whose reason for existence is to promulgate information. For repositories to enforce the latest and greatest security settings for users to access documents makes no sense and is insane if (like my repositories) we also offer the same documents over HTTP. Note, for example, that your site can’t be accessed from IE 6 or by bots running certain varieties of Java. That’s probably not a bad choice unless you need it to be accessible to the third world, which has a much older technological profile than the west. It may make sense to lock down submission / admin interfaces, particularly if these are accessed from off campus. Cheers stuart From: Alan Orth [mailto:alan.o...@gmail.com<mailto:alan.o...@gmail.com>] Sent: Monday, 15 September 2014 8:36 p.m. To: Stuart Yeates; Ivan Masár Cc: dspace-tech@lists.sourceforge.net<mailto:dspace-tech@lists.sourceforge.net> Subject: Re: [Dspace-tech] Recommended TLS cipher suite for sites using HTTPS Stuart, Interesting that you consider Mozilla's guidlines too strict. Bettercrypto.org's are even more so. :) For reference, I use a "stricter" config than Mozilla's in that I disallow SSLv3 (as even XP supports TLS 1.0), and I get an A+ on the Qualys SSL test: https://www.ssllabs.com/ssltest/analyze.html?d=cgspace.cgiar.org TLS is fun, isn't it?! Alan On 09/15/2014 01:20 AM, Stuart Yeates wrote: 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<mailto: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
Re: [Dspace-tech] Recommended TLS cipher suite for sites using HTTPS
+1 to Stuart, my only intention with https is to secure user credentials, beyond that it does not matter. *Hilton Gibson* Ubuntu Linux Systems Administrator JS Gericke Library Room 1025C Stellenbosch University Private Bag X5036 Stellenbosch 7599 South Africa Tel: +27 21 808 4100 | Cell: +27 84 646 4758 On 15 September 2014 22:28, Stuart Yeates wrote: > Both of the guidelines make complete sense if you’re a bank (or the > payroll system of a university). They make less sense when if you are a > service whose reason for existence is to promulgate information. For > repositories to enforce the latest and greatest security settings for users > to access documents makes no sense and is insane if (like my repositories) > we also offer the same documents over HTTP. > > > > Note, for example, that your site can’t be accessed from IE 6 or by bots > running certain varieties of Java. That’s probably not a bad choice unless > you need it to be accessible to the third world, which has a much older > technological profile than the west. > > > > It may make sense to lock down submission / admin interfaces, particularly > if these are accessed from off campus. > > > > Cheers > > stuart > > > > *From:* Alan Orth [mailto:alan.o...@gmail.com] > *Sent:* Monday, 15 September 2014 8:36 p.m. > *To:* Stuart Yeates; Ivan Masár > *Cc:* dspace-tech@lists.sourceforge.net > *Subject:* Re: [Dspace-tech] Recommended TLS cipher suite for sites using > HTTPS > > > > Stuart, > > Interesting that you consider Mozilla's guidlines too strict. > Bettercrypto.org's are even more so. :) > > For reference, I use a "stricter" config than Mozilla's in that I disallow > SSLv3 (as even XP supports TLS 1.0), and I get an A+ on the Qualys SSL test: > > https://www.ssllabs.com/ssltest/analyze.html?d=cgspace.cgiar.org > > TLS is fun, isn't it?! > > Alan > > On 09/15/2014 01:20 AM, Stuart Yeates wrote: > > 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]. > &
Re: [Dspace-tech] Recommended TLS cipher suite for sites using HTTPS
Both of the guidelines make complete sense if you're a bank (or the payroll system of a university). They make less sense when if you are a service whose reason for existence is to promulgate information. For repositories to enforce the latest and greatest security settings for users to access documents makes no sense and is insane if (like my repositories) we also offer the same documents over HTTP. Note, for example, that your site can't be accessed from IE 6 or by bots running certain varieties of Java. That's probably not a bad choice unless you need it to be accessible to the third world, which has a much older technological profile than the west. It may make sense to lock down submission / admin interfaces, particularly if these are accessed from off campus. Cheers stuart From: Alan Orth [mailto:alan.o...@gmail.com] Sent: Monday, 15 September 2014 8:36 p.m. To: Stuart Yeates; Ivan Masár Cc: dspace-tech@lists.sourceforge.net Subject: Re: [Dspace-tech] Recommended TLS cipher suite for sites using HTTPS Stuart, Interesting that you consider Mozilla's guidlines too strict. Bettercrypto.org's are even more so. :) For reference, I use a "stricter" config than Mozilla's in that I disallow SSLv3 (as even XP supports TLS 1.0), and I get an A+ on the Qualys SSL test: https://www.ssllabs.com/ssltest/analyze.html?d=cgspace.cgiar.org TLS is fun, isn't it?! Alan On 09/15/2014 01:20 AM, Stuart Yeates wrote: 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<mailto: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://sha.com/ On Sat, Sep 13, 2014 at 10:35 PM, helix84 mailto:heli...@centrum.sk>> wrote: On Sat, Sep 13, 2014 at 9:05 PM, Hilton Gibson 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
Re: [Dspace-tech] Recommended TLS cipher suite for sites using HTTPS
Stuart, Interesting that you consider Mozilla's guidlines too strict. Bettercrypto.org's are even more so. :) For reference, I use a "stricter" config than Mozilla's in that I disallow SSLv3 (as even XP supports TLS 1.0), and I get an A+ on the Qualys SSL test: https://www.ssllabs.com/ssltest/analyze.html?d=cgspace.cgiar.org TLS is fun, isn't it?! Alan On 09/15/2014 01:20 AM, Stuart Yeates wrote: > > 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 > <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://sha.com/ > > > > On Sat, Sep 13, 2014 at 10:35 PM, helix84 <mailto:heli...@centrum.sk>> wrote: > > On Sat, Sep 13, 2014 at 9:05 PM, Hilton Gibson > 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 Eti
Re: [Dspace-tech] Recommended TLS cipher suite for sites using HTTPS
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://sha.com/ On Sat, Sep 13, 2014 at 10:35 PM, helix84 mailto:heli...@centrum.sk>> wrote: On Sat, Sep 13, 2014 at 9:05 PM, Hilton Gibson 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
Re: [Dspace-tech] Recommended TLS cipher suite for sites using HTTPS
Hi Alan Thanks. I updated the wiki page: http://wiki.lib.sun.ac.za/index.php/SUNScholar/Secure_Internet_Connections#Example_.22server.xml.22_secure_settings Cheers hg *Hilton Gibson* Ubuntu Linux Systems Administrator JS Gericke Library Room 1025C Stellenbosch University Private Bag X5036 Stellenbosch 7599 South Africa Tel: +27 21 808 4100 | Cell: +27 84 646 4758 On 14 September 2014 09:39, Alan Orth wrote: > 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://sha.com/ > > On Sat, Sep 13, 2014 at 10:35 PM, helix84 wrote: > >> On Sat, Sep 13, 2014 at 9:05 PM, Hilton Gibson >> 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
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://sha.com/ On Sat, Sep 13, 2014 at 10:35 PM, helix84 wrote: > On Sat, Sep 13, 2014 at 9:05 PM, Hilton Gibson > 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
Re: [Dspace-tech] Recommended TLS cipher suite for sites using HTTPS
On Sat, Sep 13, 2014 at 9:05 PM, Hilton Gibson 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 -- 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
Re: [Dspace-tech] Recommended TLS cipher suite for sites using HTTPS
Thx Helix Who is the arbiter "safe ciphers"? I am not a cipher expert. Cheers hg *Hilton Gibson* Ubuntu Linux Systems Administrator JS Gericke Library Room 1025C Stellenbosch University Private Bag X5036 Stellenbosch 7599 South Africa Tel: +27 21 808 4100 | Cell: +27 84 646 4758 On 13 September 2014 21:00, helix84 wrote: > On Sat, Sep 13, 2014 at 8:43 PM, Hilton Gibson > wrote: > > Any advice here: > > > http://wiki.lib.sun.ac.za/index.php/SUNScholar/Secure_Internet_Connections > , > > would be appreciated. > > See the "ciphers" attribute here: > http://tomcat.apache.org/tomcat-7.0-doc/config/http.html#SSL_Support > > > Regards, > ~~helix84 > > Compulsory reading: DSpace Mailing List Etiquette > https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette > -- 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
Re: [Dspace-tech] Recommended TLS cipher suite for sites using HTTPS
On Sat, Sep 13, 2014 at 8:43 PM, Hilton Gibson wrote: > Any advice here: > http://wiki.lib.sun.ac.za/index.php/SUNScholar/Secure_Internet_Connections, > would be appreciated. See the "ciphers" attribute here: http://tomcat.apache.org/tomcat-7.0-doc/config/http.html#SSL_Support Regards, ~~helix84 Compulsory reading: DSpace Mailing List Etiquette https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette -- 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
Re: [Dspace-tech] Recommended TLS cipher suite for sites using HTTPS
Hi Alan Any advice here: http://wiki.lib.sun.ac.za/index.php/SUNScholar/Secure_Internet_Connections, would be appreciated. Cheers hg *Hilton Gibson* Ubuntu Linux Systems Administrator JS Gericke Library Room 1025C Stellenbosch University Private Bag X5036 Stellenbosch 7599 South Africa Tel: +27 21 808 4100 | Cell: +27 84 646 4758 On 13 September 2014 19:59, Alan Orth wrote: > Hey, all. > > I was just having a look at a few institutional DSpace instances, and > noticing that they are using sub-par cryptography. Unless you have a > specific need to use SHA1, AES-CBC, RC4, MD5, or non-DHE RSA, you should > REALLY be using the TLS cipher suite from this Mozilla guide: > > https://wiki.mozilla.org/Security/Server_Side_TLS > > They have copy/paste-able strings for Apache httpd and Nginx web servers. > > Obviously test in a development server first... but really, this is a > trivial change. You went to the trouble of buying TLS certs and setting > up HTTPS, so you might as well do it right! > > -- > Alan Orth > alan.o...@gmail.com > http://alaninkenya.org > http://mjanja.co.ke > "I have always wished for my computer to be as easy to use as my > telephone; my wish has come true because I can no longer figure out how > to use my telephone." -Bjarne Stroustrup, inventor of C++ > 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 > -- 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
[Dspace-tech] Recommended TLS cipher suite for sites using HTTPS
Hey, all. I was just having a look at a few institutional DSpace instances, and noticing that they are using sub-par cryptography. Unless you have a specific need to use SHA1, AES-CBC, RC4, MD5, or non-DHE RSA, you should REALLY be using the TLS cipher suite from this Mozilla guide: https://wiki.mozilla.org/Security/Server_Side_TLS They have copy/paste-able strings for Apache httpd and Nginx web servers. Obviously test in a development server first... but really, this is a trivial change. You went to the trouble of buying TLS certs and setting up HTTPS, so you might as well do it right! -- Alan Orth alan.o...@gmail.com http://alaninkenya.org http://mjanja.co.ke "I have always wished for my computer to be as easy to use as my telephone; my wish has come true because I can no longer figure out how to use my telephone." -Bjarne Stroustrup, inventor of C++ GPG public key ID: 0x8cb0d0acb5cd81ec209c6cdfbd1a0e09c2f836c0 signature.asc Description: OpenPGP digital signature -- 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
