Do you really want “bank grade” security in your SSL? Danish edition

I recently saw an article on /r/programming called Do you really want “bank grade” security in your SSL? Here’s how Aussie banks fare. The author used the Qualys SSL Labs test to determine how good Aussie banks’ SSL implementations really are. I thought the article was great, and gave good, actionable feedback. At the time of writing this two of the banks listed have already improved their SSL scores.

It got me thinking: how well (or badly) do banks in Denmark fare? We put our trust - and our money - in these banks, but do they really deserve it? The banks I’ll be testing come from the list of systemically important banks, more commonly known as “Too big to fail.” The list consists of:

  • Danske Bank
  • Nykredit
  • Nordea
  • Jyske Bank
  • Sydbank
  • DLR Kredit

The Qualys SSL Labs test gives an overall grade, from A to F, but also points out any pressing issues with the SSL configuration. To score well a site must:

  • Disable SSL 3 protocol support as it is obselete and insecure
  • Support TLS 1.2 as it is the current best protocol
  • Have no SHA1 certificates (excluding the root certificate) in the chain as modern browsers will show the site as insecure
  • Disable the RC4 cipher as it is a weak cipher
  • Support forward secrecy to prevent a compromise of a secure key affecting the confidentiality of past conversations
  • Mitigate POODLE attacks, to prevent attackers downgrading secure connections to insecure connections

To make this as realistic as possible, I’ll be testing the login pages.

So I’ve got my list of sites, and my test all sorted. Let’s dive right in!

Bank Grade SSL 3 TLS 1.2 SHA1 RC4 Forward Secrecy POODLE
Danske Bank A- Pass Pass Pass Pass Fail Pass
Nordea B Pass Fail Fail1 Fail Fail Pass
DLR Kredit C Fail Fail Fail Fail Fail Fail2
Jyske Bank F Pass Fail Pass Fail Fail Fail
Sydbank F Pass Fail Pass Fail Fail Fail
Nykredit F Fail Fail Fail3 Fail Fail Fail

Only one bank, Danske Bank, managed to get an A (though it is an A-). This is mostly due to the lack of forward secrecy support. If they fix this they can increase their rating to an A. They are also the only bank to enable TLS 1.2 support, and disable the RC4 cipher.

Nordea comes in second, managing a B, with some very odd results. They only support the TLS 1.0 protocol, but the list of server preferred cipher suites starts with RC4 (which is insecure). The server also sent a certificate chain with an MD2 certificate in it!

DLR Kredit achieves a C, despite the fact they are vulnerable to POODLE, because only their SSL 3 implementation is vulnerable. Their certificate is signed using SHA1, but stranger still their server didn’t send any intermediate certificates. DLR Kredit is also the only bank which is vulnerable to the CRIME attack. This allows an attacker to read secure cookies sent by the server. Disabling TLS compression is all that is required to mitigate this.

Jyske Bank and Sydbank appear to use the same server configuration as their results are equally bad. They both have disabled SSL 3, and have a complete certificate chain signed using SHA256, but fail on all other tests. In addition, both banks are intolerant to TLS versions, meaning if their websites are badly written they may stop working when new TLS versions comes out.

Finally we have Nykredit, who fares worst of all. Their server sent unnecessary certificates, signed using SHA1, which causes them to fail this test. They only support TLS 1.0 and SSL 3, but their server’s preferred cipher is RC4. Most worrying is the lack of support for secure renegotiation. This vulnerability is nearly 5 years old, and allows a man-in-the-middle to inject arbitrary content to an encrypted session.

Overall it’s not looking too good. A lot of Denmark’s biggest banks are not as secure as they would have you believe. Many are vulnerable to a lot of different avenues of attack - the most worrying being POODLE. These results are similar to those in Troy Hunt’s original article, and just go to show that just because something is “bank grade” doesn’t necessarily mean that it’s actually good.

  1. Nordea’s SSL certificate is SHA256, but they use an SHA1 intermediate certificate [return]
  2. DLR receives a C overall, as only its SSL implementations are vulnerable to POODLE, but not its TLS implementation [return]
  3. Nykredit would pass, but they provide an unnecessary certificate which is signed using SHA1 [return]

Continuously deploy Jekyll to Azure Web Apps

I’ve been thinking about writing a blog for a while now, but there are just so many blogging platforms out there to choose from. I finally settled on Jekyll as it’s really lightweight (compared to platforms like Wordpress), it has an active development community, and you can write all your articles in Markdown.

Many Jekyll users host their Jekyll sites through GitHub Pages, and there are a lot of advantages to this:

  • Free web hosting
  • Built in version control
  • Continuous deployment

However, the main disadvantage is that GitHub Pages runs Jekyll in safe mode. This means that it’s not possible to extend Jekyll with plugins. There are some ways to avoid this restriction, but they’re all awkward workarounds.

A solution

I still wanted all the advantages GitHub Pages has, but with Jekyll plugins too. The solution was to use Travis to build the Jekyll site and host it on Azure Web Apps. Travis is a continuous integration service that’s free for open source projects to use, and I’m going to use it to build my Jekyll site. Azure provides cheap, or even free, web hosting for websites and it’s what I’m familiar with.


First of all you need to create an Azure Web App.

  • Go to the Azure Portal
  • Click New > Compute > Web App > Quick Create
  • Enter the URL you want and select an app service plan

Azure new web app

On the dashboard for your new web app, make a note of the FTP host name and your deployment credentials. If you’ve forgotten your deployment credentials you can reset them from here as well.


I know I said earlier that I didn’t want to use GitHub, but I’m not actually using GitHub Pages. Travis depends on GitHub Webhooks in order to figure out when you push an update to your site and kick off a build. In addition to the standard Jekyll files you’ll need to add a .travis.yml configuration file as well as a build and deploy script. My Travis configuration looks like this:

language: ruby
  - 2.2
  - chmod +x script/build
  - ./script/build
  - chmod +x script/deploy
  - ./script/deploy

Taking it section by section

language: ruby
  - 2.2

This tells Travis that the project is Ruby based, and what version of Ruby to use - in this case Ruby 2.2.

  - chmod +x script/build
  - ./script/build

My build script in the scripts directory. This sets the execute flag, then executes it.

  - chmod +x script/deploy
  - ./script/deploy

If the build is successful, Travis will set the execute flag on the deploy script, then execute it.


I’m using html-proofer to check all the links and images on my site, and this allows me to speed up the build time by using pre-installed libraries.

Now onto the build script. There’s nothing terribly exciting here, just build the site and run html-proofer on it.

bundle exec jekyll build
bundle exec htmlproof ./_site

The real magic happens in the deploy script.

sudo apt-get install -qq ncftp

ncftp -u "$USERNAME" -p "$PASSWORD" $HOST<<EOF
rm -rf site/wwwroot
mkdir site/wwwroot

cd _site
ncftpput -R -v -u "$USERNAME" -p "$PASSWORD" $HOST /site/wwwroot .

I’m making use of a handy program called ncftp in order to deploy my site. Firstly Travis deletes the currently deployed site, then puts the generated Jekyll site on the FTP server.


To put it all together you need to configure Travis builds for your GitHub repository, and set the environment variables to allow Travis to deploy to Azure:

  • Go your your Travis profile
  • Click the slider next to your Jekyll repository
  • Go to your repositories and click on your Jekyll repository
  • Click Settings > Environment variables
  • Set environment variables for your Azure Web App where
    • USERNAME is azure-web-app-name\\azure-deployment-username
    • PASSWORD is azure-deployment-password
    • HOST is

Travis environment variables"

Remember that USERNAME requires a double backslash to escape the character in the terminal.

Putting it all together

Now that everything is all configured all you need to do is push a commit to GitHub and wait. If everything is good you should see your Jekyll site deployed automatically to your Azure Web App - though if you’re anything like me html-proofer will have picked up some broken links on your site!