Belgian citizens often use websites of the Belgian administration, such as Tax-on-web to complete their tax form (about 2,4 million users did so last year (Belga, 2014)) or open a case with the Belgian Privacy Commission through e-loket. People appear to be using these services increasingly (Belga, 2014; European Commission, 2013), and personally I certainly applaud this increased popularity of e-government.

However, a government should always take care of its citizens, certainly when it comes to sensitive data. And two recent news items made me decide to check on the current status of SSL certificates used on web properties of Belgian authorities. In January, Yeri Tiete checked the certificates of Belgian banks. About a month later, his blog post was noticed by national (and international) media and was discussed intensely. This attention was ultimately a blessing for the customers, because banks actually acted and made efforts short after to better secure their websites. But, while people can quite easily change to another bank, there is only just one federal government! So I think it is even more interesting to check on how they are doing. Apparently, people use public Wi-Fi networks for filing their taxes and this becomes an issue when the login page doesn’t automatically redirect the user to the secure HTTPS variant (White, 2015).

Admittedly, there is a lot more to consider when looking at a website’s overall security. However, a limitation of this blog post is that I will only look at the strength of the SSL certificate. The strength of a certificate is determined by Qualys‘ SSL Labs Server Test. Each certificate then gets a score ranging from A (best) to F (worst). Some things to consider:

  • Certificates which use the SHA1 hashing function can never receive A+, because it’s just too weak (Palmer, 2014; Shoup, 2005)
  • When the server uses SSL 3, the score is capped to B
  • Some Belgian services use the same certificate (with the same server configuration weaknesses) and thus have the same or similar scores
  • The domains tested are not always the main domain of a service, but rather the domain where the sensitive data is transferred (login screen)

Data

Here is the data and the scores for each service:

FOD FinanciënPrivacy Commissiee-GovCSAM Social SecurityDigifloweHealth PortaalBiztaxDIBISS
Certificate70100100100100100100100100
Protocol Support7095070900957070
Key Exchange809090909090809090
Cipher Strength908090909090909090
ScoreBBFCCFA-CC

A lot of services offered by the Belgian government are handled by the central login domain login.socialsecurity.be and is included only once. Here is the list of domains analysed:

Biztaxccff02.minfin.fgov.be
CSAMcsam.be
DIBISSorpss.fgov.be
Digiflowdigiflow.belgium.be
e-Goviamapps.belgium.be
eHealth Portaalehealth.fgov.be
FOD Financiëneservices.minfin.fgov.be
Privacy Commissieeloket.privacycommission.be
Social Securitylogin.socialsecurity.be

ratings

Some considerations

Some extra remarks regarding the ratings, per domain:

  • Biztax (C)
    • Domain is vulnerable to POODLE attack, because it still uses SSL 3, which is an “obsolete and insecure protocol” (Möller, Duong, & Kotowicz, 2014)
    • SHA1 is used, but this is a too weak signature
    • The server should accept TLS 1.2, but does only support older protocols.
  • CSAM  (C)
    • Same remarks as Biztax
    • The certificate is still valid until after 2015, however, they should better renew it earlier and use SHA2
  • DIBISS (C)
    • Same as CSAM
  • Digiflow (F)
    • Vulnerable to POODLE attack
    • If a browser tries to connect to Digiflow and attempts the use of the newest TLS 1.2 protocol, the site will no longer work
    • There is no support for secure renegotiation (explained in detail and with an example on DigiCert)
  • e-Gov (F)
    • SSL 3 is still used, but should be disabled instead, which currently makes it also vulnerable to POODLE
  • eHealth Portaal (A-)
    • SHA1 is used, they should use SHA2 instead
    • Forward secrecy is not enabled. It should be so past communications can’t be decrypted in case the private key should be compromised one day (Zhu, 2014)
  • FOD Financiën (B)
    • Many  issues the other configurations have, but not as severe
    • Not vulnerable to POODLE or BEAST (Meyer & Schwenk, 2014), but they should still disable SSL 3
  • Privacy Commissie (B)
    • Not bad, but they should disable RC4 cipher and enable forward secrecy
  • Social Security (C)
    • POODLE again
    • On a positive note, TLS_FALLBACK_SCSV is used to prevent the downgrading of the TLS protocol used

Conclusion

Too many users are potentially exposed to the POODLE vulnerability. Not sure how this is still possible since it was discovered in October of 2014 already. Also, of all the domains I tested, HSTS (Lackey, 2015) was never enabled. If you are not familiar with what HSTS is, in short, it means the website will serve its contents only over HTTPS and not over plain HTTP. While the user was always redirected to the secure page on login pages, HSTS would still be a nice addition to secure the whole domain.

Some vulnerabilities or weaknesses found will solve themselves as times goes by. The use of SHA 1 is one such example: when a current certificate is due to be renewed, the certificate authority will (very likely at least) not offer SHA 1, but only SHA 2. Additionally, browsers will start to complain, such as Google Chrome, which will warn “This site is using outdated security settings“.

Security warning on www.ehealth.fgov.be with the Google Chrome browser
Security warning on www.ehealth.fgov.be with the Google Chrome browser

Do you have other domains of the federal government that needs to be checked and compared? Or you want a new blog pots for another government (e.g. Flemish government)? Please let me know in the comments.


References

Belga. (2014a, July 17). Tax-on-web klokt af op 2,441 miljoen aangiftes. Retrieved April 11, 2015, from http://deredactie.be/cm/vrtnieuws/binnenland/1.2034859

Belga. (2014b, October 6). Toename dossiers bij Privacycommissie door datalek NMBS. Retrieved April 11, 2015, from http://deredactie.be/cm/vrtnieuws/binnenland/1.1993371

Coninckx, D. (Ed.). (2004). Overheidscommunicatie in België: een overzicht. Antwerpen: Garant.

European Commission. (2013). e-Government in Belgium 2013.

Lackey, R. (2015, February). Enforce Web Policy with HTTP Strict Transport Security (HSTS). Retrieved April 11, 2015, from http://blog.cloudflare.com/enforce-web-policy-with-hypertext-strict-transport-security-hsts/

Meyer, C., & Schwenk, J. (2014). Information Security Applications. Jeju Island, Korea. Retrieved from http://dx.doi.org/10.1007/978-3-319-05149-9

Möller, B., Duong, T., & Kotowicz, K. (2014). This POODLE Bites: Exploiting The SSL 3.0 Fallback. Google. Retrieved from https://www.openssl.org/~bodo/ssl-poodle.pdf

Palmer, C. (2014, September 5). Gradually sunsetting SHA-1. Retrieved from http://googleonlinesecurity.blogspot.com/2014/09/gradually-sunsetting-sha-1.html

Shoup, V. (Ed.). (2005). Advances in cryptology CRYPTO 2005: 25th Annual International Cryptology Conference, Santa Barbara, California, USA, August 14-18, 2005 : proceedings. Berlin; New York: Springer. Retrieved from http://site.ebrary.com/id/10528619

Wang, Y.-J., Organisation for Economic Co-operation and Development, & SourceOECD (Online service) (Eds.). (2009). Rethinking e-government services: user-centred approaches. Paris: OECD.

White, C. (2015, April 11). Two-thirds of people filing taxes do so using unsecured Wi-Fi. Retrieved April 11, 2015, from http://www.neowin.net/news/two-thirds-of-people-filing-taxes-do-so-using-unsecured-wi-fi

Zhu, Y. (2014, April 8). Why the Web Needs Perfect Forward Secrecy More Than Ever. Retrieved April 11, 2015, from https://www.eff.org/deeplinks/2014/04/why-web-needs-perfect-forward-secrecy

Image: Alan Levine

Join the conversation

3 Comments

  1. Pingback: Uw elektronische identiteitskaart (eID) kon niet correct gelezen worden. | Thomas' Miniblog
Leave a comment

Your email address will not be published. Required fields are marked *