HTTPS Best Practices

Using HTTP Over TLS (HTTPS or Hypertext Transfer Protocol Secure) helps users ensure that they are connecting to the correct web site and that their communications are protected from eavesdropping and tampering in transit. Using HTTPS for banking and e-commerce web sites is an obvious requirement, but HTTPS is also valuable for scientific cyberinfrastructure (CI), where users log in to access valuable scientific resources and rely on the integrity of their research data. Always-On-SSL describes the recommended best practice of enabling HTTPS across an entire website, rather than only specific areas of the site, to protect the user's entire web session.

The first step to enable HTTPS on a web site is to obtain a certificate for the site. CI providers should use HTTPS certificates issued by certificate authorities that are well known to standard web browsers so users do not learn to click through security warnings for so-called self-signed certificates. In many cases, CI providers can obtain HTTPS certificates from their home campus' IT department, which may be participating in the InCommon Certificate Service program or have an established contract with another certificate provider.

Tools and guides are available to assist with maintaining a secure HTTPS configuration. The Qualys SSL Server Test tool analyzes a site's HTTPS configuration to identify problems and areas for improvement. Qualys updates their test tool to check for the latest HTTPS security issues (such as the recent Heartbleed bug), so using the tool periodically can help verify that a site's HTTPS configuration remains up-to-date. Comodo and DigiCert also provide HTTPS test tools. For up-to-date HTTPS server configuration recommendations and examples, see the guides provided and maintained by Mozilla and Qualys.

What are your HTTPS best practice questions or recommendations? Post your comments below.

For more about how CTSC helps NSF projects visit http://trustedci.org/howwehelp.

Secure Coding tutorial accepted at XSEDE'14

Prof. Bart Miller will present his Secure Coding tutorial at XSEDE'14 on July 14th. With the recent coding flaws found in OpenSSL, this subject has become even more timely.

Watch this blog or the CTSC Twitter feed for more details.

LIGO and CTSC Collaborate with InCommon to Advance International Identity Federations

(5/28/2014 Update: ISGTW has run an article on this collaboration.)

A significant collaboration effort between LIGO and CTSC bore fruit this week when InCommon signed the eduGain declaration, a significant step in connecting the main identity federation in the U.S. with peer identity federations worldwide. Such peering is key to enabling international research collaborations such as the LIGO Scientific Collaboration, which has members institutions in 22 nations on five continents.

The LIGO and CTSC collaboration helped launch InCommon’s current interfederation effort by bringing this key international research collaboration use case to InCommon. CTSC and LIGO personnel (Jim Basney and Warren Anderson) chaired InCommon’s Interfederation subcommittee from its inception until now. In this role they worked with InCommon staff, notably John Krienke, to determine the best policy and technical path forward for interfederation.

Federated identity allows science facilities to leverage existing user logins at campuses and research institutions, removing the password management burden from those facilities and eliminating the need for scientists to use separate passwords when accessing those facilities. Enabling federations to interoperate across national boundaries expands the utility of federated identity for international collaborations.

The products from the LIGO and CTSC engagement are:

• Final Report for LIGO Engagement
• A Study of Three Approaches to International Identity Federation for the LIGO Project 
• InCommon Membership in eduGAIN: the LIGO Perspective
• Presentation: INFED

CTSC Engagement: Helping IceCube enhance a well-established cybersecurity program

In the CTSC-IceCube engagement, personnel from both organizations worked together to assess IceCube’s current cybersecurity program, and identify areas for improvement.  As a result, CTSC proposed a cybersecurity improvement plan for IceCube’s cyberinfrastructure, which is available publicly at http://trustedci.org/icecube/.

The CTSC team found IceCube to have a relatively mature cybersecurity program in comparison to other CI projects of similar size.

The first step in the process was to conduct a risk assessment of the IceCube project to identify assets, risks, threats and vulnerabilities. The assessment included a review of existing IceCube security policies and procedures. Members of both CTSC and IceCube participated in the assessment process to categorize and weight identified risks.  This analysis was used to determine the best way resources can be applied to further strengthen IceCube’s cyberinfrastructure.  

We thank and acknowledge the IceCube team, particularly Steve Barnet, Gonzalo Merino, Paul Wisniewski, and Matt Newcomb, for the collaborative effort and for IceCube’s commitment to information security.

Which cyberinfrastructure components are impacted by Heartbleed?

This table captures Heartbleed vulnerability information about CI components that we are aware of. If you have information to add, please send email to info@trustedci.org

Direct link to Google Spreadsheet 

Changelog:

• 4/10 11:02am ET: Added GSI-OpenSSH and MyProxy. Clarified Globus includes GridFTP and GRAM.
• 4/10 12:17pm ET: Added specific links for MyProxy and GSI-OpenSSH
• 4/11 7:38am ET: Added HTCondor, changed to Google Spreadsheet
• 4/11 8:08am ET: Added Perfsonar
• 4/15 4:12pm ET: Added XSEDE User Portal (4:58pm replaced text with URL)
• 4/23 3:06pm ET: Added FutureGrid
• 4/25 8:38pm ET: Added HUBzero

Heartbleed: Should I change my password? (And when?)

Yesterday, news of the Heartbleed OpenSSL bug swept the Internet, and lots of web site administrators worked to update software and replace potentially compromised cryptographic keys. Estimates are this vulnerability affected over half a million websites and major sites such as Yahoo Mail were vulnerable.

Today people are starting to wonder what this bug means to them, specifically should they change their passwords? It’s possible as the news spread yesterday, websites could have been compromised before they were fixed. There is also the theory that someone could have exploited this bug secretly for two years.

It’s easy to say “Yes!” and this is always a good safe default, but if you’re like me you have 100s of passwords and changing them all is a major task. This post is meant to give you some guidance as to which passwords to change and which to change first.

First, figure out your most important passwords and start with those. Think about websites (good news for SSH users: SSH isn’t affected by Heartbleed, just OpenSSL) that would cause you real worry if the password was compromised. If you’re like me, it’s online banking and other important websites such as my university login and key projects I’m a part of.

Then, figure out if those websites you use were affected. This list of the top 1000 sites is a good place to start as well as this list from mashable.com. If you don't see a website listed in those places, look to their blog or other sources of support information. Failing that, it’s probably easiest just to assume they are compromised since it would take take more effort to figure out than change your password.

Then, and waiting may be hard, but there isn’t any point in changing your password until a website has fixed their software and changed their cryptographic keys. You can wait to hear from a website or you can test the website yourself. Once they’ve fixed their software and replaced their cryptographic keys, then it makes sense for you to change your password.

And while you’re going around changing all these passwords, take the opportunity to use a password manager and a different password for each site. Using a different password for each site is the most important thing you can do improve your security and obviously you can’t remember that many passwords, so using a password manager is the best way to do that.

Yes, this is no fun for anyone. Unfortunately security on the Internet is a shared responsibility and while websites do their best to minimize impact on us, sometimes things just don’t work out.

(Edited 4/10 to add link to mashable.com list.)

Serious OpenSSL 1.0.1 "Heartbleed" Bug

On Monday, April 7, 2014, the OpenSSL project announced the existence of a serious bug in OpenSSL 1.0.1 through 1.0.1f with the potential of leaking private keys and other sensitive information from affected SSL/TLS clients and servers. The bug is in the implementation of the TLS/DTLS heartbeat extension (RFC 6520) and therefore has been called the "Heartbleed Bug".

Administrators of systems running OpenSSL 1.0.1 through 1.0.1f should promptly install the vendor fix for their operating system (when available). Administrators of impacted HTTPS servers should obtain a new HTTPS certificate using a newly generated private key, after installing the OpenSSL fix, as the existing HTTPS private key is now suspected to be compromised due to this OpenSSL bug.

References:

• https://www.openssl.org/news/secadv_20140407.txt
• http://heartbleed.com/
• http://www.kb.cert.org/vuls/id/720951
• https://lists.incommon.org/sympa/arc/inc-ops-notifications/2014-04/msg00000.html

Outsourcing Identity Management

Identity Management (IdM) in scientific cyberinfrastructure is a means to an end: provide convenient and secure access to applications, data, instruments, and services so scientists can focus on the science. Implementing a custom IdM solution can be a significant drain on resources for science projects. Outsourcing IdM can help with managing user identities, credentials, groups, and profiles. Three IdM outsourcing options that we see used in US scientific cyberinfrastructure are Globus Nexus, Agave, and Google Apps for Education.

Globus Nexus provides identity, profile, and group management as part of the Globus Platform, which is designed to support data-intensive collaborative research. Multiple research projects have adopted Globus Nexus for identity management, including US ATLAS, OSG, and KBase. Globus Nexus supports federated identities via InCommon/CILogon and Google OpenID, as well as user-managed groups. US ATLAS and OSG use CI Connect to integrate with Globus Nexus. The KBase Authentication developer tutorial demonstrates KBase’s integration with Globus Nexus via an OAuth/REST API.

Agave is a science-as-a-service platform, designed to support science gateways, that was developed by the iPlant Collaborative. Agave provides hosted identity, profile, and group management via an OAuth/REST API. Science gateways can integrate with iPlant identities (hosted in the Agave platform), use Agave as a hosted OpenID Connect interface to their existing identity solutions, or leverage Agave’s identity-as-a-service offering. For example, the Bioextract Server and CIPRES science gateways now accept iPlant identities for login via Agave, the Arabidopsis Informatics Portal and VDJServer leverage Agave’s hosted identity service, and the Texas Advanced Computing Center uses Agave with their Active Directory to provide OAuth protection to their internal and external APIs.

The Google Apps for Education collaboration platform is widely used for smaller scientific collaborations, due to ease of setup and powerful collaboration tools (Docs, Forms, Groups, Chat, Hangouts, etc.) provided out-of-the-box . External applications can integrate with Google identities and Google+ profiles via OpenID Connect. Google Apps also supports SAML SSO for integration with campus identities. Google’s Directory API provides an OAuth/REST interface to Google Groups.

What do you think about science projects outsourcing identity management? Post your comments below.

For more about how CTSC helps NSF projects visit http://trustedci.org/howwehelp.