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 <[email protected]> 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:[email protected]] > Sent: Monday, 15 September 2014 8:36 p.m. > To: Stuart Yeates; Ivan Masár > Cc: [email protected] > 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:[email protected]] > Sent: Sunday, 14 September 2014 7:39 p.m. > To: Ivan Masár > Cc: [email protected] > 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 <[email protected]> wrote: > On Sat, Sep 13, 2014 at 9:05 PM, Hilton Gibson <[email protected]> > 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 > [email protected] > http://alaninkenya.org > http://mjanja.co.ke > "In heaven all the interesting people are missing." -Friedrich Nietzsche > GPG public key ID: 0x8cb0d0acb5cd81ec209c6cdfbd1a0e09c2f836c0 > > > -- > Alan Orth > [email protected] > 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 > [email protected] > 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 [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-tech List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
