Re: Lessons learned disabling SSLv3

[Velislav K Pavlov <VelislavPavlov () FERRIS EDU>]

Nmap has NSE scripts like https://nmap.org/nsedoc/scripts/ssl-enum-ciphers.html  or Poodle for SSLv3 only which can 
help to enumerate whole subnet and output results in greppable format. This can help to build visibility and plan 
staged remediation thus limiting impact.


Vel Pavlov | Sr. IT Security Analyst
M.Sc., CISSP, C|EH, C)PTE, Security+, ITIL, A+
Ferris State University
For service requests, please contact the
Technology Assistance Center (TAC)<http://www.ferris.edu/techsupport/>


This message contains information which may be confidential and privileged. Unless you are the intended addressee (or 
authorized to receive for the intended addressee), you may not use, copy or disclose to anyone the message or any 
information contained in the message. If you have received the message in error, please advise the sender by reply and 
delete the message.




On Mar 25, 2015, at 11:03 AM, Brad Judy <brad.judy () CU EDU<mailto:brad.judy () CU EDU>> wrote:

This is a key point.  Browsers have largely caught up with TLS and you can readily run stats on the user agent strings 
in web server logs to check for non-TLS browsers like IE6 under XP.

On the other hand, system-to-system connections are harder to nail down for TLS and cipher suite compatibility.  For 
example, if you have an application that makes web services calls, but runs on an old version of Java, it might not 
support TLS.

An IDS like Bro can collect data on what versions of TLS/SSL are being used and what cipher suites, giving more 
visibility into the potential impact of disabling insecure options.


Brad Judy

Director of Information Security
University Information Systems
University of Colorado
1800 Grant Street, Suite 300
Denver, CO  80203
Office: (303) 860-4293
Fax: (303) 860-4302
www.cu.edu<http://www.cu.edu>

<image002.jpg>




From: The EDUCAUSE Security Constituent Group Listserv [mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of Thomas 
Carter
Sent: Tuesday, March 24, 2015 12:25 PM
To: SECURITY () LISTSERV EDUCAUSE EDU<mailto:SECURITY () LISTSERV EDUCAUSE EDU>
Subject: Re: [SECURITY] Lessons learned disabling SSLv3

We haven't had any major problems. We did have to be careful with a couple of legacy apps where SSL is used for 
application communication and those legacy apps couldn't use TLS. Those systems aren't accessed via browsers anyway so 
we were able to secure them in other ways.

Thomas Carter
Network and Operations Manager
Austin College
903-813-2564
<image003.gif>

From: The EDUCAUSE Security Constituent Group Listserv [mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of 
Woodruff, Dan
Sent: Tuesday, March 24, 2015 10:48 AM
To: SECURITY () LISTSERV EDUCAUSE EDU<mailto:SECURITY () LISTSERV EDUCAUSE EDU>
Subject: [SECURITY] Lessons learned disabling SSLv3

We are working to disable SSLv3 in favor of at least TLS1.0 (possibly higher) on all web servers at the University. We 
have some concerns about browser compatibility issues with the versions of TLS. All modern browsers support at least 
TLSv1.0 so we anticipate that the impact to our community will be low if we disabled only SSLv3. If we disabled TLSv1.0 
as well, it seems more browsers would have compatibility issues. Source: 
http://en.wikipedia.org/wiki/Transport_Layer_Security

For systems that are managed by the University, we can make broad configuration changes as needed, but we also have 
students and outside parties with machines not under our control. I'm wondering if other schools have gone through this 
effort to disable SSLv3 and/or TLSv1.0 and have any lessons learned or unexpected consequences they could share?

Thanks in advance,

Dan Woodruff
University IT Security and Policy
University of Rochester