SSL (Secure Sockets Layer) Standard

Purpose

This standard defines the use of SSL for Web Services systems including the acquisition and renewal of certificates.

Brief Description

Web Services will acquire and maintain SSL certificates for all hosted web sites. By default, all non-SSL connections will be redirected to SSL connections and it is recommended that this default be used in all cases, even when not required by other University policies. In order to facilitate the proper operation and maintenance of these SSL connections, certain practices are required for all sites.

Details

SSL is the Internet standard protocol for secure communications between web browsers and web servers. It serves the dual role of encrypting all communications to prevent interception and tampering, as well as verifying the identity of the web server.

SSL By Default

Web Services recommends that all web connections use SSL and will configure all sites to redirect non-SSL connections to SSL by default. A site owner may request an exception to this default practice for some or all of their site, subject to the following restrictions based on University policy:

Using SSL meets these requirements. Note that once a user logs in to a web site by any means, the communications stream contains an identifier that serves as a token that stands in for a user’s credentials. As such, those tokens are considered credentials and must use SSL.

In addition, Web Services recommends that SSL be used in all cases for the following reasons:

  • All data in transit is protected from any kind of man-in-the-middle snooping or alteration.
  • The identity of the site/server is verified to the visitor (i.e., they know they are talking to a Purdue web site).
  • Search Engines now downgrade search results that are not provided by SSL due to the prevalence of bogus attack sites.

Web Services’ Responsibilities

  • Web Services will obtain and deploy SSL certificates for all web sites hosted on our systems. In most cases, these SSL certificates are at no charge to the web site owner as the University has a bulk purchase agreement through the InCommon Federation. However, when an InCommon certificate is not supported (some software insists on certain providers), the site owner will be required to provide a University account for Web Services to use to purchase and renew the certificate.
  • Web Services will track and renew SSL certificates 30 days before expiration after confirming with the site owner. If a site is known to be on-going and the certificate is not being charged to the site owner, Web Services may renew the certificate without obtaining confirmation first.
  • Web Services will not obtain SSL certificates for sites not hosted on our systems or for servers not administered by us. Please contact Purdue System Security (PSS) directly for assistance.
  • Web Services will not provide SSL keys or access to a key to customers. If a customer needs a certificate/key pair for code purposes on one of our servers, we will assist the customer in obtaining a certificate/key dedicated to this task.
  • Web Services will track current best practices and requirements for the strength of SSL certificates, encryption algorithms, etc. and will work with PSS and InCommon to ensure they are met. Currently, certificates will use 2048-bit keys and SHA-2 signatures.
  • Web Services may disable certain SSL ciphers or algorithms as requested by PSS to mitigate vulnerabilities. This may affect the ability of some older browsers to access a site. When a disruption is anticipated and time permits, Web Services will notify customers of this change ahead of time. If time does not permit (such as during an active exploit), Web Services will notify customers after the fact.
  • Web Services will not use self-signed SSL certificates in normal, customer-facing situations.

Site Owner/Developer Responsibilities

  • Since all web pages may be accessed by SSL at the visitor’s discretion, it is vital that web site developers ensure that their site does not include “mixed content”. Mixed content occurs when the site is loaded via SSL but incorporates components (images, style sheets, JavaScript) that are not delivered via SSL. This is a coding error and can be readily detected if the site is checked using SSL before being released to the public. Many browsers now refuse to load content not delivered via SSL on an SSL protected page.

SSL Certificates for non-Purdue Domain Names

Web Services can provide SSL certificates containing non-Purdue domain names. However, since our agreement with InCommon requires that Purdue only obtain certificates for University-owned names, certain conditions apply:

  • The domain registrar must publicly show that Purdue University or the Purdue Research Foundation owns the domain name.
  • The domain must be hosted by Purdue University DNS servers.

This second condition is necessary so that the Purdue Hostmaster can be involved in the domain verification process (a process that verifies our right to obtain an SSL certificate for the name in question). When the Purdue Hostmaster is not involved, certificate updates and renewals can be delayed by non-responsive domain owners to the detriment of all.