Monday, 10 April 2017

Updating SAML Service Provider keys for Shibboleth IdsP

SAML Service Providers (SPs) maintain one or more key pairs for use when interacting with Identity Providers (IdPs). The public part of these key pairs are distributed to IdP via SAML metadata or otherwise.
SP keys are used for two purposes:
  1. The SP uses them to sign authentication requests
  2. IdP use them to encrypt attribute assertions in responses for decryption by the SP (encryption is optional, but commonly enabled)

Keys need to be replaced occasionally. This can be difficult to achieve without service disruption because the public parts are distributed and it's impractical to update all copies simultaneously. For a Shibboleth IdP, coping with replacement of an SP key used for signing isn't problematic -- a new key can be added to the SP's metadata ahead of deployment and the IdP will be happy with signatures made with either. However once two keys appear in the metadata the IdP may use either to encrypt assertions and this will only work if the SP is happy to perform decryption with either key.
For Shibboleth SPs this isn't a problem, because they can be configured to accept multiple keys for decrypting assertions while using a nominated key for creating signatures. There's a well known procedure for rotating the key on such a SP, see for example documentation on the UK federation site and in the Shiboleth Consortium Wiki. This amounts to:
  • Create new key pair on the SP
  • Configure the SP to accept either key for decryption but not use the new one for signing (by adding the new one with use="encryption")
  • Add the new key to the SPs metadata for both use="signing" and use="encryption" (or just without a 'use' attribute)
  • Wait for the metadata to propagate, or directly update all IdPs
  • Switch the SP to use the new key for signatures (by removing use="encryption" from the new one and adding it to the old one)
  • Completely remove the old key from the SPs metadata
  • Wait for the metadata to propagate, or directly update all IdPs
  • Remove the old key from the SP configuration
Some SPs don't support this. However it is only encryption that causes a problem. The main reason for encrypting assertions is to prevent users seeing what the IdP is saying about them, but in man cases there's nothing in the assertions that the user can't see by other means. So temporarily disabling encryption while rolling a SP key is a possibility. This means that the key can be rolled without downtime with the following revised procedure:
  • Setup custom relying party on the IdP for the SP that suppresses encryption. Something like this:
<rp:RelyingParty id="<SP entityID>"
   provider="<IdP entityID>"
   defaultSigningCredentialRef="IdPCredential" >

   <rp:ProfileConfiguration xsi:type="saml:SAML2SSOProfile" 
       encryptNameIds="never" />

  • Add the new key to the SP's metadata
  • Wait for the metadata to propagate, or just update all IdPs.
  • Switch the SP to use the new key
  • Remove old key from metadata
  • Wait for the metadata to propagate, or just update all IdPs.
  • Remove the custom relying party configuration
Note that this requires coordinated work on every IdP with which the SP works so it's not practical on a large scale. It will however work where there's essentially a one-to-one SP -> IdP relationship, as in many SaaS scenarios.

Tools such as the Firefox SAML tracer, the Chrome SAML Dev Tool extension and the SAML Chrome panel are  really helpful for checking that each step of the process has completed before moving in to the next.

Thursday, 9 July 2015

Mitigating recent TLS vulnerabilities

Recently discovered vulnerabilities in TLS (also known as SSL -- the protocol implementing secure web browsing and securing other activities such as email) can and should be mitigated by appropriate server configurations. Existing defaults and previously-recommended configurations may require attention to address these issues. While these vulnerabilities have been addressed in recent versions of major clients, not everyone runs up-to-date versions and not all access is from major clients.

Vulnerabilities addressed by this advice include 'POODLE' (CVE-2014-3566), 'Freak' (CVE-2015-0204), and 'LogJam' (CVE-2015-4000).

What represents a 'best' configuration depends on the capabilities of the servers involved, and of their expected clients. The best security can only be obtained on up-to-date software and only with configurations that may exclude some older clients. The following advice will provide a reasonable level of security but should be reviewed in the light of specific requirements.

The following advice is intended to be generic; specific configuration advice for some platforms appears below.

Suggestions (in order of importance):

1) Ensure that the SSLv2 and SSLv3 versions of the protocol are disabled.

Note that IE6 on Windows XP will be unable to communicate with servers that don't support SSLv3, but given its age this should be acceptable -- many major services already disable SSLv2 and SSLv3.

2) Adjust the cryptographic suites supported to exclude the following:

  • all 'export' suites
  • any using symmetric encryption with keys less that 128 bits
  • any using signatures based on the MD5 hash algorithm
  • any using symmetric encryption based on the RC4 algorithm

3) Configure Diffie-Hellman (DH) key exchange to use at least 2048-bit groups. Additionally generate a unique 2048-bit group for use in Diffie-Hellman key exchange on each server. As an alternative, it may be appropriate to disable all cryptographic suites that rely on Diffie-Hellman key exchange. Plan to upgrade systems that can't be appropriately configured.

Note that this advice does not apply to Elliptic-Curve Diffie-Hellman key exchange (ECDH) which does not currently have any known vulnerabilities. Note also that Java 1.6 and 1.7 clients may be unable to communicate with servers offering Diffie-Hellman key exchange using groups over 1024-bits long.

4) Support TLSv1.2 - plan to upgrade any systems that can't do so.

One way to test your configuration is to use the SSL Labs server test page. Aim to eliminate any issues flagged 'VULNERABLE' or shown in red, and to reduce or eliminate any marked 'WEEAK' or shown in orange. It should be possible to achieve an overall rating of at least 'B' and preferably 'A' but don't be guided entirely by the overall rating shown. The 'Handshake Simulation' section of the report can be helpful when evaluating the impact of any configuration change on clients.



Add the following directives to httpd.conf or equivalent and ensure that they are not being overridden elsewhere:

    SSLProtocol all -SSLv2 -SSLv3
    SSLCipherSuite ALL:!aNULL:!eNULL:!LOW:!EXP:!MD5:!RC4

TLSv1.2 is automatically available on systems running OpenSSL 1.0.1 or above but not otherwise - plan to upgrade systems that include only lower versions

By default Apache 2.2 only supports a fixed 1024-bit Diffie-Hellman group - plan to upgrade it. Apache from 2.4, and patched versions of 2.2 in some Linux distributions, support longer fixed groups. Unique groups can be created with the command

    openssl dhparam -out dhparams.pem 2048

and loaded into patched versions of Apache 2.2, and into Apache 2.4 with the directive

    SSLOpenSSLConfCmd DHParameters dhparams.pem

Restart Apache after making these changes.


See elsewhere for instructions on disabling SSLv2 and SSLv3.

To set cryptographic suites:
  • Open the Group Policy Object Editor (i.e. run gpedit.msc in the command prompt).
  • Expand Computer Configuration --> Administrative Templates --> Network --> SSL Configuration Settings.
  • In the right pane, open the SSL Cipher Suite Order setting.
  • A reasonable cipher suite list (from Bulletproof SSL and TLS, Ch 15) would be:


    If this excludes some old but necessary clients then consider adding:


Reboot after making these changes


The Nginx project have published instructions on how to disable SSLv3 on Nginx.

To configure cipher suites place the following in the website configuration server block in /etc/nginx/sites-enabled/default (see the LogJam pages):

      ssl_ciphers 'ALL:!aNULL:!eNULL:!LOW:!EXP:!MD5:!RC4';

Custom Diffie-Helman groups can be created with the command:

      openssl dhparam -out dhparams.pem 2048

and loaded into nginx with the following configuration:

      ssl_dhparam dhparams.pem;


See elsewhere for instructions on disabling SSLv2 and SSLv3.

Configuring cipher suites (see Bulletproof SSL and TLS):

* With the APR/Native connector
  •  Set the 'SSLCipherSuite' attribute of the 'Connector' XML element in your $TOMCAT_HOME/conf/server.xml file:

    SSLCipherSuite = "ALL:!aNULL:!eNULL:!LOW:!EXP:!MD5:!RC4
* With the JSSE connector
  • Set the 'ciphers' attribute of the 'Connector' XML element in your $TOMCAT_HOME/conf/server.xml file:

    ciphers = "TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,

Saturday, 31 January 2015

Information Systems - what we do

Building on yesterday's list of technologies use by the Information Systems team here at the University, here are some of the services that we run. Much of this will probably only make sense to people inside the University.
In addition, we contribute to a number of services run by other parts of UIS:
So now you know.

Friday, 30 January 2015

An Information Systems colophon

I've followed the work of Government Digital Service (GDS - the people behind GOV.UK) for a while. It seems to me that an organisation dedicated to “leading the digital transformation of government” probably knows a thing or two that's relevant to the digital transformation of a university.

GDS have a blog, and their list of technologies that they use is interesting. Work I've been doing recently means that I've created a similar list of the technologies used within my Information Services team here at the University. For what its worth this what it looks like:

Core servers
Base software products
  • Some services are based on existing software, including phpBB and Mediawiki
  • The Web Search service is provided by Funnelback

We rely on, and in some cases also support, a range of technologies:
Applications (incl. Frameworks, etc)
Database and other storage
Monitoring, managing and alerting
Supporting Tools
  • Central RT system for support tickets
  • Trac and Mantis for bug tracking
  • We've been experimenting with LeanKit and Asana for program and project management

Saturday, 27 April 2013

Why I think php is a bad idea

Update: a friend reminds me of which covers the same topic from a different angle.

Thursday, 31 January 2013

Getting your fonts from the cloud

The University of Cambridge's latest web style, due for deployment RSN, uses Adobe Myriad Pro for some of its headings. This is loaded as a web font from Adobe's TypeKit service. As I understand it this is the only legal way to use Adobe Myriad Pro since Adobe don't allow self-hosting.

Typekit is apparently implemented on a high-availability Content Delivery Network (though even that isn't perfect - see for example here), but the question remains of what the effect will be if it can't be reached. Obviously the font won't be available, but we have web-safe fall-backs available. The real question is what sort of delay might we see under these circumstances.  Ironically, one group who are particularly exposed to this risk are University users since at the moment we only have one connection to JANET, and so to the Internet and all the TypeKit servers.

TypeKit fonts are loaded by loading a JavaScript library in the head of each document and then calling a initialisation function:

<script type="text/javascript" src="//<licence token>.js"></script>
<script type="text/javascript">try{Typekit.load();}catch(e){}</script>
Web browsers block while loading JavaScript like this, so if can't be reached then page loading will be delayed until the attempt times out. How long will this be?

Some experiments suggest it's very varied, and varies between operating systems, browsers, and types of network connection. At best, loss of access to TypeKit results in an additional 3 or 4 second delay in page loading (this is actually too small, see correction below). At worst this delay can be a minute or two. iOS devices, for example, seem to consistently see an additional 75 second delay. These delays apply to every page load since browsers don't seem to cache the failure. 

Users are going to interpret this as somewhere between the web site hosting the pages going slowly and the web site being down. It does mean that for many local users, loss of access to TypeKit will cause them to loose usable access to any local pages in the new style.

Of course similar considerations apply to any 'externally' hosted JavaScript. One common example is the code to implement Google Analytics. However in this case its typically loaded at the bottom of each page and so shouldn't delay page rendering. This isn't an option for a font unless you can cope with the page initially rendering in the wrong font and then re-rendering subsequently.

I also have a minor concern about loading third-party JavaScript. Such JavaScript can in effect do whatever it wants with your page. In particular it can monitor form entry and steal authentication tokens
such as cookies. I'm not for one moment suggesting that Adobe would deliberately do such things, but we don' know much about how this JavaScript is managed and delivered to us so it's hard to evaluate the risk we might be exposed to. In view of this it's likely that at least the login pages for our central authentication system (Raven) may not be able to use Myriad Pro.

Update: colleagues have noticed a problem with my testing methodology which means that some of my tests will have been overly-optimistic about the delays imposed. It now appears that at best, loss of access to TypeKit results in an additional 20-30 seconds delay in page loading. That's a long time waiting for a page.

Further update: another colleague has pointed out that TypeKit's suggested solution to this problem is to load the JavaScript asynchronously. This has the advantage of allowing you to control the time-out process and decide when to give up and use fall-back fonts, but has the drawback that it requires  custom CSS to hide the flash of unstyled text that can occur while fonts are loading.

Sunday, 27 January 2013

Restricting web access based on physical location

Occasionally people want to restrict access to a web-based resource based not on who is accessing it but on where they are located when they do so. This is  normally to comply with some sort of copyright licence. In UK education this is, more often that not, something to do with the educational recording licences offered by ERA (but see update below).

Unfortunately this is difficult to do, and close to impossible to do reliably. This often puzzles people, given that the ERA licences expect it and that things like BBC iPlayer are well known to be already doing it. It's a long story...

Because of the way the Internet works it's currently impossible to know, reliably, where the person making a request is physically located. It is however possible to guess, but you need to understand the limitations of this guessing process before relying on it. Whether this guessing process is good enough for any particular purpose is something only people using it can decide.

A common approach is based on Internet Protocol (IP) addresses. When someone requests something from a web server, one of the bits of information that the server sees is the IP address of the computer from which the request came (much as your telephone can tell you the number of the person calling you). In many cases this will be address assigned to the computer the person making the request is sitting at. IP addresses are generally assigned on a geographic basis and lists exist of what addresses are used where, so it is in principle possible to ask the question 'Did my server receive this request from a machine in the UK', or even ' my institution'.

But there are catches:
  • It's possible to route requests through multiple computers, in which case the server only see the address of the last one. This often happens without the user knowing about it (for example most home broadband set-ups route all connections through the house's broadband router, mobile networks route requests through central proxies, etc.), but it can also be done deliberately. Like many organisations, the University provides a Virtual Private Network service explicitly so that requests made from anywhere in the world can appear to be coming from a computer inside the University.
  • The lists saying which addresses are used where are inevitably inaccurate. From example a multi-national company might have a block of addresses allocated to its US headquarters but, unknown to anyone outside the company, actually use some of them for its UK offices. Connections from people in the UK office would then appear to be from the US.
So, the bottom line is that you can come close to knowing where connections are coming from, but it's nothing like 100% reliable. People will, by accident or design, be able to access content when they shouldn't, and some people won't be able to gain access when they should. Organisations (such as MaxMind) provide or sell lists which can, for example, provide a best-guess of which country an IP address is allocate to. Organisations will know what addresses their networks use - the network addresses used on the University network (and so by the majority of computing devices in the University) are described here. Though beware that increasingly people are using mobile devices connected by mobile data services such as 3G that may well appear to be 'outside' their institution even when they are physically inside it.

Another tempting approach is that modern web browsers, especially those on devices with GPSs such as mobile phones, can be asked to supply the user's location. This is used, for example, to put 'you are here' markers on maps. You might think that this information could be used to implement geographic restrictions. However the fundamental problem with this is that it's under the user's control, so in the end they can simply make their browser lie. Further it's often inaccurate or may not be available (for example in a desktop browser) so all in all this probably isn't a usable solution.

If you can setup authentication such that you can identify all your users then it seems to me that one approach would simply be to impose terms and conditions that prohibit them from accessing content when not physically in the UK, or wherever. You could back this up by warning them if IP address recognition or geo-location suggests that they are outside the relevant area. It seems to me (but IANAL) that this might be sufficient to meet contractual obligations (or at last to provide a defence after failing), but obviously I can't advise on any particular case.

Update July 2014: it appears that the ERA licence has changed recently in line with changes to UK copyright legislation to better support distance learning. This probably reduces the relevance of ERA to the whole geolocation question, but obviously doesn't affect the underlying technical issues.