 |
 |
Supposedly Chrome 39 is going to mark sites with SHA-1 certs that expire in 2017 as "secure with minor errors." I'm running Chrome 39 (beta channel) and this doesn't appear to be the case, so I don't know what the current story is. Perhaps given that google.com is using a SHA-1 cert, they have opted to postpone this little "upgrade." http://googleonlinesecurity.blogspot.com/2014/09/gradually-sunsetting-sha-1.html Carl Bussema III Information Technologist Michigan State University Outreach & Engagement Phone: (517) 353-8977 • Fax: (517) 432-9541 [log in to unmask] On Thu, Oct 16, 2014 at 1:07 PM, David McFarlane <[log in to unmask]> wrote: > From what I heard on a recent "Security Now!" podcast, Google Chrome will > start marking SHA1 certificates as "insecure" some time this November (next > month). Or has Google already backpedaled on this? Anyone know the full > story? > > -- dkm > > > At 10/16/2014 12:24 PM Thursday, Carl Bussema III wrote: > >> In scanning some sites that have been secured with the InCommon >> certificates available through ITS, I'm noticing some poor grades and >> potential problems due to using SHA1. There could be some real problems >> with SHA1 certificates coming down the pipeline very soon... Chrome could >> be marking them as insecure as early as Q1 of 2015, if the certificate >> expires in 2017 (e.g., a 3-year cert bought this calendar year). >> >> Actually, it looks like the InCommon certificate itself only uses SHA1, >> so they have a bigger fish to fry there, but perhaps if one of their large >> customers starts putting pressure on them to get it fixed, they could make >> some traction. >> >> Anyone from ITS able to comment on what the plan is to get us >> certificates that meet the new requirements? >> >> Carl Bussema III >> Information Technologist >> Michigan State University Outreach & Engagement >> Phone: (517) 353-8977 • Fax: (517) 432-9541 >> <mailto:[log in to unmask]>[log in to unmask] >> >> On Thu, Oct 16, 2014 at 11:27 AM, Kim Geiger <<mailto:[log in to unmask]>kim@ >> wkar.org> wrote: >> Thank you for this, David. >> >> -- >> Kim Geiger >> WKAR Radio & Television, WKAR.org >> East Lansing, Michigan >> <tel:517-884-4766>517-884-4766 >> >> >> >>> On 10/16/2014 at 11:10 AM, David Graff <<mailto:[log in to unmask] >> EDU>[log in to unmask]> wrote: >> > Since crypto as a whole is under a lot of scrutiny with heartbleed and >> now >> > the Poodle attack, here's what we've done to mitigate things. >> > >> > Disable SSL3 in IE, enable TLS 1.1/1.2 >> > >> > This one is easy. In the Advanced Settings tab of IE, scroll to the >> bottom >> > and uncheck SSL 2/3 if either are enabled, and make sure TLS >> 1.0/1.1/1.2 are >> > all enabled (1.1/1.2 typically are not). The IE Group Policy Object also >> > allows you to configure and lock this down easily. This is the MS >> recommend >> > mitigation until they patch out SSL3. >> > >> > Other Browsers >> > >> > I haven't found a way to disable SSL3 in Chrome, but considering their >> rapid >> > update cycle they will probably patch it out for you. In Firefox, go to >> > about:config and change the value on security.tls.version.min from 0 to >> 1. >> > This will bump up the minimum protocol to TLS 1.0, disabling SSL3. This >> > change will likely come in a patch in the next few days as well. No idea >> > about Safari. >> > >> > Disable SSL3 in SCHANNEL, enable TLS 1.1/1.2 >> > >> > Unfortunately there isn't a built-in group policy object to do it, so >> the >> > attached SSL-TLS Config.reg file will do it for you. It disables SSL3 >> (along >> > with SSL2, and PCT1 if they were enabled somehow) as well as enabling >> TLS >> > 1.1/1.2 if they are supported on the OS. XP/2003 only supports TLS1.0, >> but >> > it will ignore the reg keys for the protocols it doesn't have and is >> safe to >> > do across the board. >> > >> > Install Server 2003 AES Hotfix >> > >> > <http://support.microsoft.com/kb/948963>http://support. >> microsoft.com/kb/948963 >> > >> > If you still have any 2003 systems kicking around, install this hotfix >> to >> > add support for some basic AES ciphers in addition to the RC4 (bad) and >> 3DES >> > (okay) ones that it comes with. It won't apply to XP, but nobody is >> still >> > using any of those systems at this point, right? ;) >> > >> > Define SCHANNEL SSL Cipher Suite Order >> > >> > Policies\Admin Templates\Network\SSL Configuration Settings\SSL Cipher >> Suite >> > Order >> > >> > This one needs to be done through GPO, might be possible to do through a >> > registry merge but I'm not sure where they keys live. Use the attached >> > schannel config.txt file to define which cipher suites should be used, >> in >> > order of preference. The first ones use elliptic curve key exchange >> which is >> > very good, but only supported on newer devices. The last three on the >> list >> > (TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA, >> TLS_RSA_WITH_3DES >> > _EDE_CBC_SHA) >> > are your legacy suites to support old devices. Android 2.3 , Java 6, and >> > Server 2003 clients with the mentioned hotfix will use the first two AES >> > suites, XP systems or 2003 systems without the AES hotfix will use the >> 3DES >> > suite which is still secure at this point. If you don't have any 2003/XP >> > systems on your network, you can probably drop 3DES. >> > >> > With all that done, your HTTPS IIS websites should be validating like >> this: >> > >> > <https://www.ssllabs.com/ssltest/analyze.html?d=ipf. >> msu.edu&hideResults=on>https://www.ssllabs.com/ssltest/ >> analyze.html?d=ipf.msu.edu&hideResults=on >> > >> > Which is about as good as you can get it for now without cutting off >> Android >> > 2.3 devices, which there are still a good number of floating around. >> >>