How SSL/TLS secured web sites are practised in internet land:

the ✓ok web site mark and lock in the browser

are unnecessary misleading?

Teus Hagen, 11th of November 2010

NLUUG autumn “security” conference, Ede, Holland.

Copyright: GNU FDL

Suggestions for the to-do list of Neelie Kroes

Abstract

In order to make the SSL/TLS security protocols, encryption schemes and controlling hash functions really work in internet land, they need to be configured well. In practice not much attention has been paid to the SSL/TLS configuration of internet web services for secure web host access and pri-vate transport of data (WWW, email transport, email postbox management, private networking, re-mote access).

Policy security documents and assessments of the use of such requirements are not operational nor required by web site certification or rating organisations.

However good SSL/TLS assessment tooling is available. Rather easily SSL/TLS configurations for web servers can be made much more secure, to reach a quite high and recommended level. Even most end user applications can be configured to require a sufficiently secure connection over the internet.

For a list of more than hundred key web sites in Holland in various categories (internet banking, governmental web sites, healthcare, web shops and internet services, academic web sites, and inter-net security organisations) the security level of their SSL/TLS configuration has been assessed by SSL Labs in July-October 2010. The results give too much bad food for thought.

Executive Summary

Trust in security measures for protecting communication over the internet is heavily influenced by what the end user perceives from the arrangements taken: the quality and persistence in reviewing of ranking or certification “authorities”, updated standardized security policies as “enforced” in in-ternet land. One technical core factor to achieve this are the security arrangements throughout the SSL/TLS protocol layer. In a rather short time frame a much better security level can be reached without much costs.

The status by 31st of October 2010 of security arrangements implemented by key web sites in Holland is presented. The assessments done via SSL Labs, a collection of tools for evaluating internet SSL/TLS security measures, show that web site configurations have to be updated for all categories of web sites: internet banking, governmental e-desks, healthcare (login sites for central and local databases and service sites), web shop trade and services, student service desks, internet security consultancy organisations and certificate authorities.

The paper ends with a page on: Closing remarks, conclusions and opinions.

Teus Hagen – SSL/TLS sec. in Holland NLUUG security & privacy conf. Nov 2010 V1.4 1/44

Comments on the results for the privacy and integrity part of the communication:E.g. local government internet civil service desks should not use self signed certificates or use inse-cure encryption ciphers. A 40-bit cipher (crackable within minutes) should not be offered by either side when negotiating encryption strength. The end user does not get much clarity of e.g. the strength of the security scheme in use and how it relates to the currently accepted level of security. The configuration of the SSL/TLS server software needs to be updated on most of the servers.A simple action which can lead to a much better situation. However technicians are not served well today with security policies of their organisations. Nor is there much help from verifying ranking and certification organisations who clearly focus only on trade and legal requirements today.

Authentication of either end point:Server certificates (needed for the authentication part of the procedure to establish a connection) are used to identify the organisation; the host names in certificates are often cumbersome (e.g. wild cards in names or omission of server host name and domain name are impossible to check). The names in the certificate are (at best) only checked against the domain name registry by the Certifi-cate Authority (CA), which is in itself not secure yet (DNSSEC application and deployment will take still some time). The Certificate Authority (CA) accreditation is not well regulated, and due to different jurisdictions and market customs in which the CAs reside (mostly in the USA), not much is to be expected from them. The accreditation of a CA is mostly in the hands of operating system manufacturers /distributors and internet browser distributors. E.g. one computer can have more than one CA trust list. By definition these lists differ.

All sites in the list were expected to operate with a secured web site. Only 30% are operating with a certificate signed by a “trusted” CA: 14% with DV (Domain Validated) certificates and 16% with EV (Extended Validation) certificates. EV certificates promise: web host name registration, trade registration, identification/ownership of web site and organisation are all checked. An EV certificate is offered for about €100 per year.The PCI DSS 21 security standard (initiated by credit card companies) does not say much more than “use a strong cipher” in the security measures for SSL/TLS. Clearly much more is needed to achieve trust in the security arrangements implemented. Only 40% of the web sites assessed in Holland were PCI compliant. The other security standard developed especially for e-commerce is FIPS 140-2 (2007, NIST USA). FIPS is more detailed. However none of the assessed web sites in Holland were FIPS ready.

A special note about the healthcare web sites: these web sites are probably focussed on authenticat-ed and authorized access. About 50% of the healthcare web sites with a special login facility use no protection at all (open transfer of account name and password over the internet). Those web sites have not been investigated any further. The web sites assessed in this investigation consist of web sites for centralised database access (e.g. central electronic health register and related web sites), web sites of hospitals, state healthcare (GGD), local healthcare, healthcare institutes. The outcome of the assessment, even compared with web shops, is showing signs of severe naivety.

It is strange to see that web sites like Facebook, Twitter and LinkedIn have a higher security rating than all Dutch internet banks. After one year of the discovery of the renegotiation security hole still 44% of the internet banks have not fixed this problem.

For the end user:User certificates are hardly used by end users or by web site servers. Since many account names and most of the time also passwords are saved on the end user computer, and since such data is easy to recover most of the time, the use of individual user certificates is strongly advised. E.g. instead of

1 PCI DSS 2.0 is mostly about minor tweaks (disable SSLv2 and weak ciphers). See Computer World article of Jaikumar Vijayan (August 2010). In E-Commerce Developer (May 2010) Luke Fritz goes more deeply into the PCI Requirements (4).

Teus Hagen – SSL/TLS sec. in Holland NLUUG security & privacy conf. Nov 2010 V1.4 2/44

using persistent encrypted cookies, and browser fingerprinting which are privacy sensitive, why not use the certificate of the individual which is on his ID card?

Because the Mozilla browser Firefox can be used on all computers available on the market today, and also Mozilla was the initiator for the Secure Socket Layer (SSL) protocol followed later by TLS (the recommended one), a Firefox-based example for enforcing negotiation of a FIPS compliant se-curity level is provided. However with some web sites (e.g. internet banks) one will not be able to establish such a secure connection. One cannot expect from the end user that he will adopt per web site his browser configuration.

The first thoughts will go to WWW web site communication. Others are email transport, email postbox handling, web mail, remote (command) access, file transport, etc. As these functions are based on the same underlying SSL/TLS software, configuration of the servers can be dealt with in the same (easy) way. However the enforcement of a proper security level to be used for a connec-tion is more difficult to configure by the end user.

contentsAbstract...............................................................1Executive Summary.............................................1

Preface: Internet land in the digital world can learn from lock land in the physical world...........................4

DNSSEC protocol layer:is the IP address correct?.....................................8

Conclusion: ...................................................9Some conclusions about DNSSEC and state of configuration............................................10

SSL/TLS protocol layer:is our communication between the two of us?..11

Conclusions about the CA's.........................14SSL/TLS protocol layer..................................15

Conclusions: ................................................16The SSL/TLS assessment tooling.................17

The SSL Labs SSL/TLS assessment .............18Category Internet banking: ........................22Category Government: ...............................23Category Healthcare: .................................24Category Web Shops: ..................................24Category Education: ...................................25Category Internet High Technology: .........26

Closing remarks, conclusions and opinions. . .28

Appendix A: DNSSEC help and figures........29

Appendix B:Web shop certification and CA accreditation..33

Appendix C: SSL/TLS help and figures..........36

Appendix D: spreadsheet internet banking.....37Appendix E: spreadsheet governmental...........38Appendix F: spreadsheet web shops.................39Appendix G: spreadsheet healthcare...............41Appendix H: spreadsheet education.................42Appendix I: spreadsheet internet security........43

Teus Hagen – SSL/TLS sec. in Holland NLUUG security & privacy conf. Nov 2010 V1.4 3/44

Preface: Internet land in the digital world can learn from lock land in the physical world.

The old fashioned lever tumbler lock (in Dutch 'klavierslot') originates from far before the epoch. The double acting lever tumbling lock was invented as late as in 1778. This simple type of lock is still used nowadays as locking system for the back door of houses. With rather simple tools like e.g. two picking keys, or “runner key” (a set for Lips-Nemef locks is available for below € 100 ) this lock can be lock picked easily . The lock pick set has about 12 runner keys. Chubbs locks however have a build in lock picking detection provision.

At a not much later date in 1784 the cylinder lock was patented. Later in 1844 Yale invented the pin lock. This type of lock has usually 5-6 pins. Each pin has a certain length (0-9) to allow only one key for the installed set of pins to turn the cylinder and unlock the door. The amount of different keys is defined by the amount of pins and the length of the pins (e.g. 106 possibilities or in digital world notation 20-bits security). Drilling the lock is a brute and fast way to open the lock permanently. The good locks are equipped with a drilling prevention. Lock pick-ing was a clever invention to open these locks. And of course the newer type of locks are equipped with a lock picking prevention.

In 2004 videos in internet land showed the open-ing of the Kryptonite locks with a simple ball point . In 2005 at the Chaos hackers confer-ence in Berlin Barry Wells of the Toools group2 in Amsterdam showed a flaw which appears in all cylinder locks: with a special key (the “9's” key) 99% of the cylinder locks can be opened easily without any trace. Many videos on YouTube show this and even “bumping” key sets are sold for less than € 100 (e.g. LockPicks.com for a set of 33 keys and DBC Locksmiths for a named key of 3 UK£). Marc Weber Tobias wrote a good analys is of the bumping tech n i que .

“Digital keys” is the latest invention to improve

2 See also “Ten things everyone should know about Lockpicking & Physical Security” slides from Deviant Ollam (Toools group).

the lock security scheme. In the same session Barry Wells showed (the long video recording of this session) a flaw in a digital locking system of Winkhaus. Winkhaus makes a “highly secure” expensive digital lock (Bluechip). It uses a contact-less security chip with 128-bits strength. In internet land 128 bits is expected to be not too weak and enjoys a commonly accepted

strength. However opening the lock was un-expectedly very easy: a strong magnet will force the small solenoid switch to unblock the handle so one could easily open the lock. The manufac-turer went back to the drawing room.

All of these technical measures could make it hard to enter the room via the door. In Holland there is a central body Stichting Kwaliteit Gevel-bouw (SKG) which does certifications and secu-rity ranking of e.g. locks. This is a non--commercial fully independent organisation. So for locks there is a list of requirement available, called NEN 5098 (revised in March 2010). Of course SKG does not mention bumping in its “security policies” . They mention only the “brute force and timings” as the security mea-sures in their requirements needed to e.g. unlock the lock.

However more than 95% of the homes and even offices are locked with very simple cylinder locks. The back-doors have in 50% of the cases a lever tumbler lock. Why should one use brute force if the key to the lock is often just under the door mat or flower basket? Or one of the win-dows is left easy to open? Or remove the pins in the hinges? Knowing that social surveillance and/or arrangements are usually not present.

All of these threats are just physical and have nothing to do with the identity or authentication of the person. The threats are physical threats.

Cars are often better protected. E.g. the cylinder lock is much better then the lock in the front door of one's living house. Is that really so? Read e.g. the paper “Experimental Security

Teus Hagen – SSL/TLS sec. in Holland NLUUG security & privacy conf. Nov 2010 V1.4 4/44

Analysis of a Modern Automobile” by Karl Koscher and others (2010 IEEE Symposium on Security and Privacy). They report about the way in which they were able to remotely take over the full control of a modern car which is controlled by a fairly common Electronic Control Unit (ECU). The picture here shows their message on the speedometer of the car.

As shown on the Black Hat conference (July 28, 2010) one is able to bypass the front door lock and get control via the remote “monitor feature” e.g. phone, or even via internet to make the ATM to pay out. The next step is clearly to apply this type of hacking and feed the message board at the side of the road with your marketing mes-sage?

Bruce Schneier writes more about this false sense of security and how to handle it in his book Secrets and Lies. In his other book Beyond Fear he asks: “Is on-line shopping with credit cards especially risky?” and “Will a national ID card better protect us against terrorism?”. Bruce is the author of “the Bible of cryptography”: Applied Cryptography. And co-author of the ex-cellent textbook Cryptography Engineering (e.g. why exact names in (X.509) certificates will not work). Follow also his blogs to learn what is go-ing on in the digital security world.

With a short look into the world of “physical locking” and its security history one can use this opportunity to look with another perspective at security in the digital world. And learn many lessons:

• “locking” measures cost money, energy and even break emergency routes. The arrangements should be commensurate with the value of the protected “goods”. However the value of a “good” is an emotional one. Look at it from the “at-tacker point of view” (lock picking is an art), from a “defender viewpoint”and from the viewpoint of the spectator;

• every protecting mechanism is much easier to circumvent in some way;

• every protecting mechanism does not last forever and will be out of date unexpect-edly;

• every complex protecting mechanism will be broken in a simple way at some point in time;

• technology is one of the many compo-nents which should build trust. Apply technologies in a simple and understand-able way;

• cylinder locks constitute the main lock-ing technology today. People learned to cope with this uncertain technology;

• the evolution speed in internet land is 100 times faster than in the physical world. While technologies evolve, apply better ones as soon as possible, as good as possible;

• internet land is much bigger than only your regional borders;

• duplication in internet land is much easi-er and is very cost effective;

• openness is a safeguard for this speedy and effective evolution;

• it is much easier to use social engineering to get in;

• quality assurance certification should be non-commercial. But it is not keeping up;

• be practical, is it worth the trouble or is it just PR?;

• would it be nice when door locks can “smell” your DNA in order to identify and authenticate you?

The focus in this report is to see how well an end user is protected in the current internet prac-tice.

Take for example somebody using a web brows-er for communicating with some web server and using its Universal Resource Locator (URL) to establish a secure connection. The first step is to make sure which real server you are targeting. Is the server really who he says he is? And ... maybe also the other way around: the server needs to know exactly who you are.

The next step is an exchange of protection func-tions negotiated for this particular communica-tion session. One should make sure (again from both sides) that the communication between the

Teus Hagen – SSL/TLS sec. in Holland NLUUG security & privacy conf. Nov 2010 V1.4 5/44

two parties is kept very private.

The steps in more detail:

1. First find the destination and service port e.g. URL and (secure) method of communication: https://www.host.com. Notice that web (WWW or HTTP method) has its secure friend HTTPS. So has the mail service (SMTP) its secure friend ESMTP. Mailbox services like IMAP4 and POP3 also have their secure friends (IMAP4S and POP3s). Each service uses a fixed protocol port number at the server. With this combination of service port and host name one is able to reach the service. As computers can only understand numbers one will need support from your system and internet to translate the host name and service name to an inter-net address and port number.

2. With the internet address of the origina-tor (this address may change in time and even become anonymous via a proxy), and with some “values” (a fingerprint and values taken from the user's comput-er software environment) the server may collect some “idea” of the end user. The server will use such values as identifica-tion of the user; examples are account name and password, cookies and ever--cookies (cookies which never go away), tokens, information from other sessions and perhaps even browser fingerprinting3 to get as much info about the end user as possible. Note that some of these values can eventually breach your privacy... All info from your computer can be stolen (brute force is the easiest way). If

3 Browser fingerprinting: the end user browser provides a lot of information to the web server software: which browser, which version, which computer OS, language, IP number, browser modules installed, browser mod-ules details, time zone, screen size and colour depth, installed system fonts, cookies and super cookie test. Enough to make this connection unique to say 1 in a million. See the paper “How to defend to this” Panop-ticlick.eff.org. Or test your browser. How much your browser reveals about you can be seen with BrowserSp y.dk .

this information was not encrypted you are out of luck. If encrypted with an easy to guess password you are out of luck again. And when did you turn your back and left your computer “open” lately? You thought the computer was the only one in your house?

One is referred to Peter Steiner's cartoon “on the internet nobody knows you are a

dog” in the New Yorker (July 1993). Add to the saying in the cartoon: “a dog is quite clever and hides his bone carefully outside the desktop computer”. Most dogs in Hollland have an ID chip under their skin to identify them. So only

dogs can make a real binding between end user and desktop computer.

3. While using the host name (www.host.com) the IP address has to be looked up. Domain Name Service (DNS) is the tool used for this. But how secure is this?4 See the chapter “DNSSECprotocol layer: is the IP address correct?¨ of this paper for more status information on this. This DNSSEC layer is needed since the authentication part in the SSL/TLS layer (the certificate with the certified host name), is uncertain (sloppy check of the name, too many alternative names, defects5 in the certificate name , etc.).

4. In this step the SSL/TLS security layer in the protocol is arranged: authentication information of the certificate(s) is ex-changed to identify the partner(s), and encryption schemata and strength of ci-phers for the communication is negoti-ated and enforced as defined in the secu-

4 Steve Friedl of Unixwiz.net wrote a good explanation in his article “An Illustrated Guide to the Kaminsky DNS Vulnerability” (Sep 2008) of how DNS works and what the weakness is about.

5 In 2009 Dan Kaminsky and Moxie Marlinspike showed a possibility to trick the domain name valida-tion via the infamous null-byte in a name. The vulnera-bility has been assigned as CVE-2009-2408.

Teus Hagen – SSL/TLS sec. in Holland NLUUG security & privacy conf. Nov 2010 V1.4 6/44

rity settings (on both sides!). See the” SSL/TLS protocol layer: is ourcommunication between the two of us?“ chapter of this paper.

5. When all previous steps are taken the au-thentication and privacy of the communi-cation is established and secured. But only as long as the the session takes place and only as long as neither part leaves this tunnel. E.g. no side peeking (e.g. http://www.example.com/text.html or a redirection to another host) from either end. For a peek aside one has to renegoti-ate the secure tunnel again...

There are a few basic elements which play a role and make this complex:

✔ Authentication on both sides: do you re-ally know who is talking to you; is the party really who he says he is? And is somebody (and can that entity be trusted) guaranteeing the identity? In the digital world: is some trusted identity or a col-lection of entities (Web of Trust) “sign-ing” the identity document (data)?

✔ Is the communication channel really pro-tected (encrypted)? Can no one at any moment play the “man in the middle” (MITM) trick? Is the tooling used strong enough to resist disclosure in proper time? Is the encryption technique used strong enough and is the amount of pos-sible keys large enough (e.g. certainly not below 128 bits)? Is the private key kept really secure (e.g. which private key ar-

rangements, which people are involved, who has key access)? Was the seed for the key pair really random and unknown? Was the key pair initiation audited? Are the security arrangements described and maintained?

✔ The encryption algorithm (RSA, DES, el-liptic curve, etc.) and signing algorithm (MD56 (insecure), SHA17 (weak since Nov 2009), SHA2, SHA3) for the com-munication is negotiated. On both sides the set of algorithms which can be used are configurable. Is there a weak possi-bility which can be chosen? Is the configuration used just standard and thus weak?

The next chapter describes the first step or layer in the communication process, the DNS(SEC) layer: is the party who he says he is. Can this host identification layer help in practice to dis-cover problems in the layer where the protection of the real communication is taking place? Is my internet bank really at the other end or is it my neighbours internet dog?

6 MD5 was discovered in 2008 to be insecure for signa-tures, as the study “MD5 considered harmful today : creating a rogue CA” of Alexander Sotirov and others made public. See also the paper.

7 Bruce Schneier in his article “Cryptanalysis of MD5 and SHA: Time for a New Standard” where he states that it is time to move away from SHA1. The NIST Computer Security Center recommends to not use SHA1 after 2010 (tomorrow) and suggests 4 newer signing (hashing) algorithms to be used. SHA3 has to be added soon and has to be published in 2012.

Teus Hagen – SSL/TLS sec. in Holland NLUUG security & privacy conf. Nov 2010 V1.4 7/44

DNSSEC protocol layer: is the IP address correct?

Computers use an internet address (number) to communicate with each other. Humans (and soft-ware) use names (e.g. host name and domain name). The Domain Name Service (DNS), operational since the 1980's, is a distributed database which can do the translation (binding) of a name to an internet address and the other way around. To accom-plish this the desktop user will have installed the internet address of a host providing DNS service, usually a “DNS Resolver”. His internet provider (ISP) will maintain such a Resolver, but one can also install a resolver just by oneself. In the case that the end-user computer address is automatical-ly assigned by the ISP, the address of the Resolver to use is also automatically provided to the end-user (desktop) computer. Firstly one needs to be certain that the a trusted Resolver host is used, that a trusted DNS host in the distributed database is used and that the address “resolved” is reliable (e.g. signed). DNS does not provide this security arrangement (and neither does the automatic inter-mediate Resolver configuration!8).

In 1999 Paul Vixie proposed a simple but valuable extension to DNS: EDNS. It uses bigger data packets, so you have to update your firewall for this! In this way one remained backwards compati-ble with DNS. DNSSEC, the security enhanced version of DNS, uses the so called “DO”-bit of EDNS. So EDNS is a prerequisite for allowing DNSSEC traffic. The DNSSEC operational question is: “is there a signature in the form of the so called RRSIG record in the answer for the real “A record name” for the name the end-user provided in his URL? E.g. was the name www.digid.nl, authenticated host name and so its IP address the real IP to get to the e-desk of the Dutch govern-ment?

It took a long long while to get DNSSEC9 initiated but with the “public10” signing of the highest Root “.” domain in July 2010 and e.g. the “.NL” Dutch domain, maintained by SIDN, in September 2010 it may get there. One can ask several DNSSEC procedural questions to raise the trust:

1. What about the signing process and documentation? The signing process for the Root was an open and published process. There is an extensive set of documentation for the process and maintenance available. The DNSSEC Root Key (top domain) is split (secret sharing via Sham ir's algo rithm ?) among seven people. But how was the signing process for SIDN's .NL domain done11?

2. Which encryption/signing algorithms pairs were practised (4 out of 6 still use the vulnerable MD5 or outdated SHA1 as hash function)? Of the defined set of encryption/hash pairs (RSA/MD5, DSA/SHA1, RSA/SHA1, RSA-SHA1-NSEC3-SHA1, RSA/SHA/SHA256, RSA/SHA512) the strong pair “8” (RSA/SHA256) is found to be used the most. Appendix A DNS Visualization tool describes in more detail and in which cases SHA1 is still used as hashing (signing) function.

3. Besides the signing action of the main top domains, the question is: is the software of the DNS service providers ready, or better, do they support EDNS and DNSSEC? The RIPE

8 The configuration of the address of the Resolver (the entry point for the name/address search of the DNS service) is done at the computer of the end-user. If the computer is hacked e.g. via Java in the browser, this Resolver address might be hacked. If the Resolver address is provided in an automatic way, this is done at a very early stage in the in-ternet connection process (DHCP). This phase has no more protection than that equipment (and so (remote) configu-ration) is controlled by the Internet Provider.

9 Hardening the Internet , the impact and importance of DNSSEC, a paper (Feb 2009) from SURFnet gives a good tu-torial on DNSSEC.

10 Olaf Kolkman witnessed the Root Key generation.11 In September 2005 Olaf Kolkman described the DNSSEC Key maintenance procedures: RIPE documents. Are the

processes/procedures audited? In the SIDN archives the signing procedures (FIPS-140 level 3 compliant) for the .NL domain can be found (PDF file).

Teus Hagen – SSL/TLS sec. in Holland NLUUG security & privacy conf. Nov 2010 V1.4 8/44

statistics show that 60% (the statistics are quite stable for August/September 2010) of the DNS servers are ready. The statistics obtained from stats.l.root-servers.org show that only 3 out of 1000 Resolvers do a DNSSEC validation (figures from September 2010). The impor-tant question for the end-user is similar: “which of the DNS Resolvers of e.g. Dutch ISP's are running DNSSEC enabled Resolver software? It is about 60% (see the table in Appendix A Dutch ISP's: support DNSSEC functionality with the results of a test of Dutch ISP's done in September 2010). Note that usually the ISP will only allow their own customers to use their Resolver, so the test is just a guess. A cautious conclusion: rather unexpectedly some of the major ISP's are not ready.

4. A BSI study for DNSSEC support in German home routers (and internet modems) in 2008 showed that 4 out of the 36 tested home routers supported DNSSEC. The 36 home routers cover 90% of the German “ISP connection” market. This study was based on tests which had a similar outcome in Sweden and the UK. Home (modem) routers act as a DNS proxy for the home desktop computers. Many of those home routers do not allow manual installa-tion of a remote Resolver and so the user is not able to choose a trusted one if he wants to. Many routers and modems need be upgraded to fully support DNSSEC.12

There is a report that a DNSSEC validated request for a host name brought a very common home router to it's knees.

5. Say for the DNS services all of the DNSSEC software, firewall configuration and routers are ready, what about the core of the data: the signing of the records in the DNS distributed database? An assessment of the status for any host name can be done via Sandia National Laboratories by using the DNSViz tool. A table of a test on 16th of October 2010 for a limit-ed hand-chosen set of names can be found in Appendix A DNS Visualization tool.

Conclusion:

Far too many problems still to be solved (e.g. 1 day latency in a Root Key server). www.icann.org and www.isc.org are (fully) secured (of course; and is your computer con-figured to use this?), but e.g. within the Dutch .nl domain no (?) domain is fully secured (yet). One web site is pretty close (CAcert.org). See Appendix A for tips how they did it. Hence there is no need to expand the DNSSEC assessment to more Dutch host names. More details in Appendix A:

DNSSEC, what can an end-user do already?

At the end-user side it helps (as long as DNSSEC is not common) to see a “secured” status indication in the browser's URL bar if the host has an address which was signed in DNSSEC. For other applications (software like Sendmail, Postfix, libspf, OpenSSH, ncftp, Jabber) there are patches available.

For Firefox there is an extension or Add-on DNSSEC Validator which gives a idea about the status: “not se-cured by DNSSEC”, “name secured by DNSSEC, but not your computer”, etc.

12 .CZ NIC provides a detailed report of DNSSEC support in different router hardware available on the market. Most of the assessments are up to date: August 2010.

Teus Hagen – SSL/TLS sec. in Holland NLUUG security & privacy conf. Nov 2010 V1.4 9/44

DNSSEC is not the guarantee to get to the right server. A computer or server can have different names or one name can represent more than one server. Also names will change in time. Users make typos and it is difficult to see for an end-user if www.tools.org is the same as www.toools.org (the one that we needed here). Sometimes the user is redirected to another site with a different name without much notice (e.g. mijn.postbank.nl access is redirected to mijn.ing.nl, www.nibcdirect.nl, with no SSL/TLS protection, one is redirected to sparen.nibcdirect.nl, logging into www.hyves.nl one is redirected to secure.hyves.org again without any notice). The naming problem is one major reason why governments use social “security” numbers for individuals and trade registration num-bers for organisations. An identical solution for the naming of e.g. individuals and organisations is not there in internet land. Maybe it is time to put a hash of one's DNA in the digital identification documents which then can be used for authentication? Together with a fast DNA hashing device it should solve the account/password authentication problem.

An intermediate solution: to avoid the waiting time for DNSSEC to become fully operational there is some help! DLV.ISC.org has installed a DNSSEC Look-aside Validation (DLV) Registry. If you are running BIND version 9.4.3-P2, 9.5.1-P2, 9.6.1, or later versions as your DNS resolver, you can get into DNSSEC at your convenience. See BIND DNSSEC configuration the DLV ICS help documentation. Also Unbound versions 1.1.0 and later provide support for employing the DLV reg-istry.

Some conclusions about DNSSEC and state of configuration

The rollout of DNSSEC has just been started and is now only a few months old. At this mo-ment the constant warning that the host name is not secured in DNS does not make much sense for the end-user. To have the DNSSEC applications ready to validate the host name makes much sense. For now the initiative of this summer makes a promise for the future...

The routers provided to connect the home computer to Internet need to be upgraded for DNSSEC. Maybe it is time that the ISP makes a new home router or modem available for the end user.

As the SSL/TLS protocol layer is, let's say mangled and gives a very complex idea of the identity of the communication partner, one needs DNSSEC to get more information about the validity of the (name / address) combination of “the other end”.

The DNSSEC security technique has fully arrived in 2010. The challenge is now to config-ure it right, maintain it, and have it openly reviewed and evaluated.

And... do not forget to stamp out MD5 and SHA1.

Make “whois” (has host name owner information) publicly available again and have the information records validated and maintained. Today too many records are just out of date.

Teus Hagen – SSL/TLS sec. in Holland NLUUG security & privacy conf. Nov 2010 V1.4 10/44

SSL/TLS protocol layer: is our communication between the two of us?

Tutorial on SSL/TLS

When internet software (e.g. web browser, e-mail handler) has identified the address of the other party (has linked the host name to the IP number of the server via DNS), and if one wants a secure (authenticated and private) method of communication, the computer will have to use the SSL/TLS internet protocols. Today the SSL protocols have all moved to TLS for security reasons, so the name SSL is misleading. Still the old common word and defeated name SSL is used in internet land.

The Secure Socket Layer (SSL; last version is 3) was initiated by Netscape in 1995 and evolved in time to the protocol Transport Layer Security (TLS; last version is 1.2). These protocols make inter-nally use of a wide range of standardized and well studied encryption algorithms like DES, RSA, el-liptic curves, etc., and also hashing algorithms (MD5, SHA1, SHA2, SHA256, etc.). Each algorithm by itself can use a variety of strengths13. A strength is expressing the amount of different key possi-bilities (e.g. 10-bit is equal to 1024 different keys; 210 ~ 103). The higher the better.

What is a hash?The hash of a particular amount of data (a digital document) gives you a single (big, but smaller than the whole document) number. The number is supposed to identify the data in a more manage-able way. If that number (say N) is unique for the document, it can represent the document without disclosing its content. So for two different documents the hash number should always differ. When they do not, it is called a collision and this hash system will break (it is a harmful hash function). The collision of hash numbers is considered to be unacceptable. E.g. so the hash function MD5 is discovered to be harmful. In 2009 it was discovered that the SHA1 hash should also be considered to be harmful. See MD5 for more explanations. The birthday paradox14 explains in an easy way that changes of collisions are easily underestimated.

For SSL/TLS encryption two keys are in use, the public/private key pair. What is encrypted with one of the two keys can only be deciphered with the other key of only that particular pair. With the trick to make only one key public and the other very private, one obtains two application functions: 1. one can send a message encrypted with the public key, after which the message can only be read by the private key holder (to be used for privacy) and 2. for a message encrypted with the private key one can say: only the private key holder, the originator, can have encrypted this message (to be used as authentication).

Conclusion: A digital signature in a digital document is not much more than the hash number of that document encrypted with the private key of the owner. There are two prerequisites here: the hash algorithm should not be harmful (not collisions), and for the well accepted encryption algorithm the public key should belong to the owner in an authoritative (and certified) way.

But..., no one should be able to reproduce (again re-“invent” the random number used in the key) in any way. The production of the key pair is using a random number. The quality of randomness is just as important as keeping the password to the private key secret. The randomness in the key pair generation procedure is a quite underestimated risk factor.

: for the public key part one needs to be sure that this key part really belongs to the owner. And also the information which goes with the public key (e.g. the name of the entity, email contact address, functions of use for this key, etc.), should have been checked via some “authority” or chain of

13 Choosing the appropriate key strength might be challenge. Help is provided in the article Cryptographics Key Length Recommendation from BlueKrypt (July 2010).

14 Birthday Paradox: only 50% chance of two persons with same birth date in a 24 persons class room (explanation in a white paper of Access Data; 4 page pdf file).

Teus Hagen – SSL/TLS sec. in Holland NLUUG security & privacy conf. Nov 2010 V1.4 11/44

authorities leading to this information, the certificate. This set of information is called a (X.509) (Public Key) Certificate. The Certificate Authority (CA) who (digitally) signs this certificate says with its signature (hash of the certificate information encrypted with the private key of the CA) that the information of the certificate belongs to the certificate holder, the one who owns the private key. The public key of the CA is available from a list of “trusted” CA's as assembled on the file system of the computer of the end-user. In order to keep things secure and outside control of third parties the private key should never be in any way shared with any outsider (CA's, even accredited ones, are too often offering to generate the private key e.g. for the (Extended Validation or EV certificate holder).The weak points with SSL/TLS (not the technique, but again this is clearly the practice):

• The CA accreditation problem:The private/public key pair: The CA is the authority to state that the public key and authenti-cating information (name, etc.) is correct and reliable. The security procedures (authentica-tion part) fully rely on this. E.g. the name of the entity on the certificate, the host name, al-ternative names, email address, etc. should be correct and identifiable. E.g. the certificate should not provide a lot of alternative names. All the CA's should agree which information is on the certificate, so the public can rely on this. However the standard used is “common practice”. The server certificate has to have the host and domain name. Too many have no host/domain name at all.The CA should be accredited15 (audited) not only once, but periodically. Today there is no such thing as one CA accreditation body or common sense for one in internet land.The information on the certificate should be checked periodically by the CA (in practice this is done only at certificate purchase time).

• Certificate weak information problem:The private/public key pair generation is done and should be done, only at the end user side. What quality procedures are used there? Are they well defined (e.g. in the so called security handbook16)? And are they certified in some organized way? How securely is the private key kept? Is the server certificate kept at 128 servers around the campus? Is the CA survey-ing the use of the certificate s signed by him? Are there documents describing the mainte-nance requirements?For the certificates in use in e.g. a browser session (this can be the certificate of an end-user in a certificate login session17 and/or the certificate of the web server) one needs a reliable and non-misleading end-user notice system (yes, User Interface design is a complex job). The information about the other party's name has to correspond with the information ob-tained e.g. via DNSSEC (hence the chapter about DNSSEC) in a simple, reliable and under-standable way. The name on the certificate should be clear: no wild cards (e.g. not *.theunis.org), and not covering all the departments of the organisation (University of Eindhoven) when not needed.

• SSL/TLS configuration problem:When the SSL/TLS protocol is initiated, the involved parties (e.g. your browser and website server) will negotiate which the encryption/hash functions is used. The quality and strength of the security protocols is defined by the configuration at both sides. Notice that if the web

15 The web site SSL shopper maintains a rating list of X.509 CA's. Reviews are entered by web site visitors. The top down list is: DigiCert, SwissSign, Startcom, Entrust, GlobalSign, Trustwave, Verisign, GoDaddy, Network Solu-tions, GeoTrust, Comodo, and Thawte.

16 See for a good starting point “An Introduction to Computer Security; the NIST Handbook” (Oct 1995!) of National Institute of Standards and Technology, US Department of Commerce. Or for a more technical approach the security policy templates from the SANS web site. This is the security policy of the CA CAcert.

17 One still has to encounter a web shop with an account login service using end-user X.509 certificates as well. The configuration to get this supported is rather simple and solves a lot of login/password problems at the end-user side.

Teus Hagen – SSL/TLS sec. in Holland NLUUG security & privacy conf. Nov 2010 V1.4 12/44

server offers a very weak function, that weak and insecure function can be used by any internet dog. For the end-user the lock on their browser will denote only that SSL/TLS is activated, and not that e.g. the null/MD5 insecure algorithm is operational for this user now.

Anyone should have their X.509 certificate signed

Certificate Authorities (CA's) offer 4-15 types of certificates (how complex can you make it?) for (web) servers and individual use on the market. All certificates have to be signed by some Certifi-cate Authorities (CA). All accredited certificates on the market: e.g. Domain Validated (DV) and Extended Validated (EV) Certificates. EV Certificates are oriented purely to commercial (web) servers. With some Googling one will discover that EV Certificates are often “on sale”. Three ex-amples: EV certificates from Verisign for about € 100 (one year), from Startcom.org for about 199 US$ (two year) or godaddy.com for 3 years 50 US$/year. The requirements to obtain an EV certifi-cate as investigated are too simple to be true: just a record in the public phone book and/or extract from some Trade Office, or declaration from any lawyer(!?)

Thawte (Verisign), Startcom.org and CAcert are CA's which use authentication/verification on a web of trust (WoT) based scheme. WoT: the more people who assess that “you are who you say you are” the more trust. This type of web of trust procedure is purely used for certificates of individuals. Strangely enough the web of trust procedure is clearly not used for organisational (DV/EV) certifi-cates (too complex, too bothersome, too much work, to much experience required?).

The Certificate Authority (CA)In order to get a CA accredited, the CA has to be accredited with the whole range of computer sys-tem software manufacturers and “distributors”: OS distributors, browsers, etc. They all have similar CA acceptance requirements18: policies for security arrangements, signing certificate process, validation of information process, privacy policies, etc. All differ in some sense. In the end the CA is audited for one of them. The audit is paid by the CA. For each of them a new audit and for every period again and again. The periodic recheck is however not (yet) common practice (should Ubuntu require a periodic audit for Verisign?) Nor does it mean that once the CA is accredited by one “distributor” the CA is automatically listed by some other “distributor”. E.g. a green trust-bar

18 CA criteria: David Ross (Mozilla) started to describe the criteria: “Say what you do, do what you say, and prove it!”. These criteriaare still in draft (Dec 2008). See also the CA criteria as defined by Microsoft and Mozilla. CA.com is one US effort to structure and centralize the CA criteria.

Teus Hagen – SSL/TLS sec. in Holland NLUUG security & privacy conf. Nov 2010 V1.4 13/44

Indicator in one browser (say Internet Explorer) will not be automatically (or should) show green in another browser (say Mozilla Firefox) on the same computer. If it does one can question it.

For the CA the accreditation process is a complex and costly event. For an organisation based on (highly technical) volunteers and a small budget the CA criteria has been proven to be one step too far. This does not mean that the arrangements and measures taken by such an organisation are of lower quality than for a commercially operating CA. On the contrary. All this is sad as it puts the CA market fully in non-EU (and so non-EU jurisdiction) commercial hands and it does not provide extra security. Trust can be paid for....

It is uncommon that a CA will check or audit their customer. And if so: where are the published re-views? The maintenance and application of certificates is left nearly free to the CA customer (in a certificate purchase contract some CA's will put some requirements). Once the certificate is pur-chased and information checked, the use of the certificate is not reviewed periodically. Renewing the certificate is mostly dependent on a periodical payment to the CA. The use of an expired certifi-cate is without shame.The SSL/TLS tests shown in this report will not show all this. The thing to achieve is that e.g. the web shops will have proper security policies in place and web shop accrediting organisations will require such policies. In September nearly all web shop accrediting organisations in Holland have been approached with the question for such (technical) security policy requirements. None of them were found to have such requirements and checks. See Appendix B Web shop “guarantee services” for an overview. Something for the consumer organisations to put at the top of their to_do require-ments list for web shops and web services?

The easy to do SSL/TLS security configuration parts

What can the end user do?:Make sure you have the X.509 certificate manager installed in your browser, say the Mozilla certificate viewer and key manager add-ons for the Firefox browser and Thunderbird email handler. Make sure you have the server certificate installed for your VPN, mail postbox ser-vice (IMAP4 and POP3), for your email transport (MTA) services (Sendmail, Postfix, Qmail, etc.), chat (Jabber), wiki (MoinMoin, WikiMedia), and for web services (Apache). The server certificate configuration and installation is rather straight forward on Linux-based systems. Usually a template is ready to go for most applications.

The complex (server) parts: Make sure that the services use the same server (is the domain name the same as the DNSSEC name?) and that the server certificate resides on a well protected and manageable (disk) location. Use encrypted file systems.

Assess the configuration of the web site:In September 2010 an assessment was done of SSL/TLS configurations in use on about 130 web sites. The list of web sites consists of those web sites which should have a certain level of security measures in place (web shops, internet banks, e-desks of governmental organisa-tions with an internet desk, etc.). This assessment gives an impression of the signing “au-thorities” of the server certificates used today. Whether the CA who was signing the server certificate is an accredited (trusted) one, is a matter of opinion. But in any way the server certificate should not be self signed (there are too many cases). One could even say that even a CA should not make use of a self (co)signed certificate (just an opinion). An overview of the CA's found in the certificates of Dutch web sites is in Appendix B: list of signing CA's.

Teus Hagen – SSL/TLS sec. in Holland NLUUG security & privacy conf. Nov 2010 V1.4 14/44

Conclusions about the CA's

• A CA is one trust factor in the authentication process. DNSSEC and the certificate authenti-cation information should (and do in some way) support each other in a simple and error avoiding way;

• Certificate applications (configurations) are not assessed. A trusted accreditation structure for CA's, as well for server certificate applications is needed (a quality assessment);

• The name on certificates will probably not correspond to the (URL) names “typed in” and should be checked via the DNSSEC protocol layer. The current browsers check the host name against the domain name(s) in the certificate. Redirection is bypassing this. A typo in the host name is everybody's pitfall.

Do not allow the pop-up saying “this certificate is not trusted, OK yes?” play a game with you. Review the offered certificate!

• Use your personal certificate to authenticate (IMAP4S, POP3S, logging into your account, etc.). How easy is it to get the login account name and password from the storage in your computer?19

SSL/TLS protocol layer

When the identification and authentication phase is passed, the proper security tunnel for encryption of the session can be built. When this secure/private tunnel is left for whatever reason, a new ses-sion, so new tunnel, should be built (securely renegotiated). The man in the middle (MITM) should not be given any chance at such a moment. The configurations on both ends define the encryption/ hashing scheme or “cipher suite” to be used for this private communication channel. The closed lock icon shown in the browser will only show that the handshake process for an encryption/hashing scheme was successful. Nothing more. E.g. a weak or even insecure scheme could have been cho-sen, still the lock pad is closed. In the latter case both ends are “guilty” to the scheme chosen for a session. The one who configured the server should be the one who knows best and he can! The blame is his cookie.

What can the end-user do?For the end-user side there is a way to configure the browser Firefox to only use the security “requirement” standard for FIPS 140-2 (three simple steps to follow: disable SSL and enable only TLS, enable FIPS internal PKCS module, and disable all non-FIPS SSL cipher suites)20. In this way one can make Firefox 2 or 3 requiring the web server to be fully FIPS compliant. After having done this in your Firefox configuration, a minor but irritating problem shows up: Firefox will now refuse any add-on update or installation via Mozilla: an insecure connection is playing a game with you (Mozilla can you simply fix this?).For other end-user applications however there is not much documentation at hand to make the ap-plication requiring to be FIPS compliant.

19 Have a look at OpenID and a new initiative WebID from within the W3C organisation. WebID or FOAF+SSL is a secure authentication protocol that enables the building of distributed, open and secure social networks: the Social Web. One of the problems with this type of authentication is that it adds traceability (privacy problem) where only identification is required.

20 For the ING internet bank one has to enable still the non-FIPS cipher suites ssl3.rsa_rc4_128_md5 and ssl3.rsa_rc4_128_sha!

Teus Hagen – SSL/TLS sec. in Holland NLUUG security & privacy conf. Nov 2010 V1.4 15/44

What can the the system administrator do?As most server software for the secure communication part makes use of OpenSSL, the open source toolkit for SSL/TLS, configuring the web server software, email handling, VPN (Apache, Sendmail21, Postfix22, Dovecot23, etc.), is quite similar and straight forward. The openssl command provides a good mechanism to show the configured encryption suites for some configuration entry and even to test the operational server.

See for a starting point e.g. the Apache web site: SSL/TLS configuration hints. To make it FIPS140-2 and PCI DSS-2 compliant use these two configuration statements: “SSLProtocol ­ALL +SSLv3 +TLSv1” and SSLCipherSuite “HIGH:!MEDIUM:!LOW:!SSLv2:!EXP:!NULL:@STRENGTH”. AND test this with the command: “openssl s_client ­connect localhost:https ­ssl2” . One should not see any SSL information. The command “openssl ciphers 'HIGH:!MEDIUM:!LOW:!SSLv2:!EXP:!NULL:@STRENGTH'” shows the cipher suites to be enabled.

And so the command “openssl ciphers FIPS” will show the FIPS compliant cipher suites. OpenSSH and other “secure” server software are also built upon OpenSSL. So for those the way to go is similar.

There are two cipher suite related reference standards defined for e-commerce and e-banking over internet:

FIPS 140-2

FIPS 140 is the US Federal Information Processing Standard 140 of the Cryptographic Module Validation Program (CMVP). The latest version is FIPS 140-2 (end of 2007). FIPS is an U.S. gov-ernment standard and provides a good standard benchmark for implementing cryptographic soft-ware. A must for e-commerce. The Guidelines for selection and use of TLS Implementations (NIST; the reference is PDF file) specifies the best practices for implementing crypto algorithms, as well as handling the key material and data buffers, and how to work with the operating system. The FIPS compliant cipher suites are (currently): DSA , ECDSA Sign Verify, SHA1, SHA256, Triple-DES (CBC), AES (CBC), HMAC-SHA1, HMAC-SHA256, RSA Sign/Verify (PKCS #1), and ANSI X9.31 DRNG. Notice that SHA1 is to be stamped out of this collection in 2011. FIPS defines four levels of security measures for the different levels of “goods” to be secured.

PCI DSS-2

The Payment Card Industry Data Security Standard (PCI DSS) is defined by the Payment Card In-dustry. It was initiated in 2006 by several international US based credit card companies.

The latest update from PCI DSS 1.2 (2008) is version 2 (August 2010). PCI DSS however is fo-cussed on payment transactions e.g. in wireless LAN situations. Unfortunately PCI DSS specifies only a requirement for “strong encryption”. The word “strong” is left undefined. Based on older versions one could interpret this as: at least 128 bit key cipher, no export strength algorithms and no SSLv2 should be used (see the Digicert White Paper).

The web sites of most Dutch banks as well as the Association of Dutch Banks have been assessed in September/October 2010. In addition a questionnaire with the results has been sent by email to each

21 Sendmail configuration (sendmail.mc) help: “APPENDDEF(`confENVDEF', `­D_FFR_TLS_1')dnl” and for LOCAL_CONFIG add “O CipherList= HIGH:!MEDIUM:!LOW:!SSLv2:!EXP:!NULL:@STRENGTH”.

22 Disable SSLv2 and weak ciphers in Postfix: set the options “smtpd_tls_mandatory_protocols = SS-Lv3, TLSv1” and “smtpd_tls_mandatory_ciphers = high” (or “medium, high”?).

23 Disable weak ciphers in in Doveco t (Feb 2010) described by Jason Brown.

Teus Hagen – SSL/TLS sec. in Holland NLUUG security & privacy conf. Nov 2010 V1.4 16/44

of these organisations. The questions were e.g. about arrangements for the FIPS 140 or PCI DSS, and other technical security requirements in their web operations. No references to this type of documents have been found for this research part. See also the assessment results done via SSL Labs for these web sites.

Conclusions:

There are several cipher suite configurations available for the various categories of security arrangements.

Compliance enforcement e.g. via internal security policy prescriptions or bodies to enforce or to check compliance for the various internet commerce branches, is not well established.

The SSL/TLS configuration assessment tooling

Beside the commands sslscan24 and openssl there are assessments offered on internet, which provide you with more details of the SSL/TLS configuration of a so called secured web site. SSL Shopper provides such an assessment service, but the SSL Labs web site run by Qualys provides a more extensive assessment tool. Also take a look at the “sslstrip” (MITM: use sslstrip to convert https to http!) and “sslsnif” tools from Moxy Marlinspike25. This software provides one with more deep checking mechanisms.

SSL Labs web site assessment figuresIn 2009 Ivan Ristic (author of “Apache Security” and “Modsecurity Handbook”, publ. Feisty Duck, available in electronic format, constantly updated) initiated the Qualys SSL Labs web site26. This web site has an overview of SSL/TLS test results for many “HTTPS” sites world wide. The “SSL Server Rating Guide” (2009; the reference is a PDF file) offers an excellent way to do assessment of the configured SSL/TLS configuration at the server side without much need for SSL/TLS ex-perts: score tables (easy figures to compare with others site configurations), protocol support, key exchange, cipher strength, certificate authority and certificate information (e.g. website host name, expiration type, signing, certificate encryption/hashing, etc.), FIPS 140 and PCI DSS compliance status, etc.

The Public Server Database and SSL Server Test is an excellent SSL/TLS server configuration as-sessment27 tool to help you with setting up and checking your SSL/TLS configuration.

A 2010 survey by Ivan Ristic, presented at the Black Hat USA 2010 conference , has been published in September 2010. Some of his highlights:

• Inconsistent name configurations e.g.: www.example.com points to another address than example.com. Different hosts on port 80 and 443. Not the URL host name on the certificate.

• more than one IP address for a host name but different SSL/TLS configurations;• Self signed certificates, and/or private CA certificates;• No mix SSL and http; No redirections; One plain text link is enough to be compromised;

24 SSLS can is a SourceForge project. For most Linux distributions there exist a ready to install version. It provides the user with a list of accepted and not accepted cipher suites and an OpenSSL view of the server certificate.

25 Have a look at the Black Hat talk (July 2009) and paper (Feb 2009; 99 slides in PDF file) by Moxy Marlinspike “New tricks for defeating SSL” where he shows that a lot can be done via the certificate e.g. making use of the MD5 collision defeat (Dec 2008, MD5 considered harmful today, Sotirov and others).

26 As an alternative (besides SSLScan) to do an assessment of a HTTPS web site one could use the OWASP testing guide.

27 Homin Lee, Tal Malkin and Enrich Nahum describe in their paper “Cryptographics Strength of SSL/TLS servers: current and recent practices” (link refers to 9 page PDF document) an assessment of over 19.000 servers. They de-scribe a positive trend.

Teus Hagen – SSL/TLS sec. in Holland NLUUG security & privacy conf. Nov 2010 V1.4 17/44

• Using SSL only for authentication (ready to be hijacked);• Not using secure cookies;• Not using EV certificates (a mistype will seduce the end user to enter and accept a connec-

tion to the wrong place);

Ivan Ristic's closing remark:

“SSL is a rare application security area where we can make things vir-

tually 100% secure, with relatively small effort. Why not get it right?”

The SSL Labs SSL/TLS configuration assessment

Results for a list of Dutch HTTPS web sites

The SSL/TLS configuration assessment values of the described list of host names in Holland (as-sessment values are from July - October 2010) are all taken from The SSL/TLS configurationassessment tooling figures generated by the SSL Labs web site. An extensive effort was made to present and collect feedback for collected figures to the web sites involved. The emails were sent to the web site managers (webmaster-, postmaster-, info-user or via web mail of the web site). Oc-casionally when no mail handler was discovered within any of the covering domains (e.g. exam-ple.nl in stead of web.example.nl) , and also when there was doubt about the security of the site, the web mail function of the web site was used to obtain a more useful contact email address. When re-sponses required a corrective action, another assessment was initiated. Some categories of web sites (e.g. internet banks) make it hard to get in contact with them, as well to get real technical or policy information about their security policies. E.g. no bank or web shop certifier replied on the request for policy documents. At 31st of October 2010 a second assessment of all web sites have been taken and figures were updated.

The list of web sites in Holland used in the tables presented in this report was compiled at hoc. E.g. the hosts which can be thought of being well known web sites of that particular branch were chosen. Due to time constraints the list is a very limited one: only 170 web sites. So from the assessments figures obtained one cannot draw general conclusions in a statistically correct way. For one branch (internet banks) nearly all banks known as internet bank were included. The comments on internet banks may be statistically correct because of this. Note that banks in this category do different types of banking. Each class within this category will probably have to use different security require-ments: internet private accounts (e.g. ING, ABN-AMRO, Rabo), asset accounts (e.g. Westland Utrecht), and those with purely savings accounts (operating with only one money transfer link to a private account at another bank (e.g. NIBCdirect)). The security requirements may differ for this reason.

The list of Dutch web servers is divided in the following categories (each with their own level of “desirable” security level requirements):

• i_banks: internet banks;• e_gov.: a mix of governmental, semi-governmental (e.g. police, DigiD) and local govern-

mental “e-desks”. DigiD is a national civil authentication web site for most governmental in-ternet services. Each municipality has, or will have within a short time frame, an internet desk for civil services;

• healthcare: web hosts with a login authentication facility to authenticate the user for access to medical (private) documents. Central medical registers, state health centres, medical insti-tutes, local healthcare, physician access points for hospitals, etc.

• e-shop: web shops of all types: trade, services (e.g. partner search service), assurances, so-cial networking (Hyves), etc.;

Teus Hagen – SSL/TLS sec. in Holland NLUUG security & privacy conf. Nov 2010 V1.4 18/44

• edu: web sites used by e.g. academia for providing student services (information, schedules, messaging, rating, etc.).

• i_sec: internet consulting, internet service provision, certificate authorities. E.g. those who know what internet and security is about.

One little change has been made in the general rating of the SSL Labs figures: from the three rat-ings for protocol, key exchange and ciphers (three percentages) the real average is calculated . So this figure does not drop to zero for any other reason. In the SSL Labs figures the average rate (per-centage) is dropped to zero in case the CA who signed the certificate of the web site is not accredit-ed, or when the certificate had expired, or when the certificate was revoked. In this overview the av-erage percentage figure is left as real average. The semantics of the A (best) to F (low) alphabetic rating scheme of SSL Labs have been left untouched.

In the overviews a web site with an F-rating from SSL Labs may still have a high percentage aver-age score rating. SSL Labs gives an A-rating score when the average score percentage is about 80% and the CA is accredited (some say trusted).

How are the assessments figures processed for this report?The assessment values obtained from the SSL Labs web site have been fed into a spreadsheet. In this way the web sites within e.g. the e-shop category can be easily compared. Since the web sites within each category will have to protect about the same type of “goodies”, they should have about the same type of security measures in their SSL/TLS web site configurations. The assessment data for the Dutch web sites in the list has been converted from HTML to records with TAB separated fields. After that process the values were fed into a spreadsheet.

The colour of the cells is set to green (opinion: this is an OK value), salmon (opinion: this element in the configuration needs special care), or red (opinion: this is not OK). In the spreadsheets with the details of the assessments values a web site's cell is set to full green if everything is found ok (an argumented opinion).

To ease the understanding of the spreadsheet, the elements (columns in the spreadsheet) which have all the same value (e.g. no TLS 1.2 or TLS 1.1 support, no weak or insecure cipher suites, all RSA/SHA1 (!) certificate signatures, etc.) have been made “hidden” in the spreadsheet, so they do not show up.

The tables shown in this report contain only those columns which have valuable differences be-tween the web site assessment values (e.g none of the sites accepted TLS 1.2 protocol layer; none had a revoked certificate in use; all accepted TLS 1.0; web sites with self signed certificates had no revocation method, all had a RSA/SHA1 (!) signature, etc.).

Teus Hagen – SSL/TLS sec. in Holland NLUUG security & privacy conf. Nov 2010 V1.4 19/44

The figures for all web sites: the SSL Labs A – F-ratings

The following spreadsheet table will give a more detailed picture. The percentage of the ratings are the averages per category and a total sum. In the percentage average columns the background colour of the cell will be green for an average percentage higher than 80% (most of the web sites in this category have a percentage rating higher than 80%, good) and the background colour will be orange for those with average percentages below 50% (bad). Notice the amounts of insecure cipher suites still in use, and the amount of SSL2 protocols still configured.

Be aware that the configurations can be easily improved (feedback showed: for some web sites who took immediate action it was less than 30 minutes of work).

The nitty-gritty details of the outcome of the Dutch web site assessments

The shown assessment figures in the table below have been collected from end of July to October 2010. Some figures are time dependent, e.g. some of the server certificate expiration dates are just around the corner and expiring in a week time. There has been a very intensive attempt to confront the web masters with their assessment figures. In order to have some comparable figures the assessment figures from SSL Labs for some well known web sites have been studied, like e.g. cert.startcom.com (A 93%), www.linkedin.com (A 88%), www.twitter.com (A 88%) and www.facebook.com (A 85%). None of these are failing on

Teus Hagen – SSL/TLS sec. in Holland NLUUG security & privacy conf. Nov 2010 V1.4 20/44

35%

4 %2 7 %

9%

2 6%

SSL Labs rating for all

A is high, F is low

ABCDEF

i_sec 79% 81% 80% 74% 83% 53% 100% 88% 88% 19% 75% 13% 69% 0% 19% 6%healt hcare 59% 59% 63% 49% 64% 18% 100% 100% 100% 73% 88% 42% 9% 0% 73% 3%edu 59% 88% 63% 53% 63% 33% 100% 100% 100% 75% 100% 38% 25% 0% 75% 0%e-shop 69% 76% 73% 57% 71% 42% 100% 100% 100% 36% 83% 21% 31% 0% 60% 5%e-gov 58% 88% 63% 47% 63% 37% 100% 100% 100% 71% 92% 21% 25% 0% 75% 4%i_bank 77% 75% 76% 76% 80% 44% 100% 100% 100% 26% 87% 22% 65% 0% 17% 0%Report_configs 69% 7 6% 7 2 % 62 % 7 3% 35% 1 00% 99% 99% 4 6% 1 00% 2 6% 4 0% 0% 51 % 4 %

ca

t eg

ory

av

. ra

t in

g

CA

tru

st e

d

pro

t oc

ol

ke

y

ex

ch

an

ge

cip

he

r

MIT

M?

TL

S 1

.0

SS

L 3

.0

SS

L 2

.0+

SS

L 2

.0

se

ss

ion

re

su

mp

t io

nin

se

cu

re

ren

eg

.P

CI

co

mp

lia

nt

FIP

S r

ea

dy

# w

ea

k

cy

ph

s#

in

se

c

cy

ph

s

i_secedu

healthE-sho p

E-go vi_bank

0

5

10

15

20

A

B

C

D

E

F

63%

25% 6%

27%

12%

54%

0% 0% 3% 2% 8% 8%

13%25%

26%

41%

44%

13%0%

38%21%

0%

20%

0%

25%13%

44%30%

16%25%

SSL Labs rat ings per cat egory

categor ies%

rating

values which were not reflected in the rating percentage elements. All of these organisations are based in the US. All these web sites have better figures than any of the Dutch list. So these web sites can be used as an “HowTo” example.

The security measures for a web site depend mainly on opinions of executives, management, techni-cians, customers, branch organisations, opinion makers and the public. Of much help for the admin-istrators dealing with the system configuration, could have been policy documents defining the technical criteria, state of technology, or self regulation security policy documents and guidelines (e.g. the NIST FIPS 140-2 security documents, the PCI DSS-2 documents). No guidelines howev-er were found from or for the particular branch/category of web sites in the Dutch web site list used. The lack of those documents is not much help for the technician managing the web site configura-tion, who in fact has to answer the effective question: what level of security arrangements is ex-pected to be installed? Nor is the lack of those documents of any help for the public opinion about what level of security arrangements is to be expected, which could answer also his question: “what are the security arrangements to be configured to enable a a highly secure connection?”. Both ends of the communication line can make or break it.

Here it is said again: the web site configuration can often easily be improved to boost the security situation to a higher level, like a score above 80% i.e. good, as concluded from the feedback ob-tained.

For the following part the explanation of the assessment figures from SSL Labs web site are “opin-ions”. The goal of publishing this report is to improve this “bad situation” of security arrangements within a rather short time frame to a far better and more acceptable level. And ... to create more trust of the end-user in the longer term by having security policies, certifications, former assessments, easier security arrangements at the user end, etc. defined, published and maintained.

Where does one have to look for in the spreadsheets? See for full details the spreadsheet printout (the pages of Appendix C and following. These pages are A3 landscape). The “full green” elements (columns) in the spreadsheet tables denote:

Web server certificate:

The signed certificate should be an EV certificate from a carefully operating (periodical-ly certifying and audited) and generally (?) trusted CA (e.g. revocation method is in place);

Web host name on the certificate should be easy to check against their DNS(SEC) name. Not 128 so called Alt. Names. The server certificate should list the host/domain name of the web site. The DNS RR record should refer to the domain name in the certificate. The DNS alias (CNAME) used should be in the Alt. Name of the certificate. The auto-matic “www.” host name of the organisation domain (e.g. example.com) should be in the certificate. Both should have the same host (configuration);

The certificate should not be expired (none were revoked);

Encryption/hash functions:

The average (enabled protocols, key exchange, enabled cipher suites) should be above 80% (green);

No use of weak, or even insecure encryption/hash algorithms;

FIPS 140-2 compliant or at least PCI DSS-2 compliant;

No cipher strength below 128-bit;

Enough good ciphers suites for the end user to choose from.

Teus Hagen – SSL/TLS sec. in Holland NLUUG security & privacy conf. Nov 2010 V1.4 21/44

SSL/TLS protocols:

No SSL 2.0.

Session/transport security:

No arrangement that MITM is possible (insecure renegotiation28);

Secure session resumption;

Use of strict secure transport.

The category “internet banking”

The e-commerce web site list of the assessment with the category internet banks has 19 banks and Ideal (central organisation for PIN payments) operating in Holland. Probably all banks providing internet banking or providing a basic money transfer service in Holland are in this list. The web sites in this category of the list of web sites is in fact representative for internet bank-ing in Holland29.

Some i_bank web sites have more than one server serving (e.g. mijnbankzaken.gilissen has 3 servers). Not all servers use the same name in their certificate. Mijn.postbank.nl is silently redirected to mijn.ing.nl. www.nibcdirect.nl is silently redirected to sparen.nibcdirect.nl.

Only five of 28 web sites have a full green rating (Frieslandbank, ABN-AMRO, ING, Rabobank, SNSbank, sparen NIBCdirect). Two banks used an expired certificate. 56% of the websites is PCI DSS compliant (PCI is defined just for this branch). None however is FIPS 140 compliant.

Six banks have a not trusted CA flag for some reason. Nine (e.g. DNB bank) out of the 28 i_bank assessments have a MITM possibility. Four banks allow to use weak (40-bit) ciphers. Only 38% use an EV certificate.

Six (21%) of the 28 i_banks have an SSL Labs F-rating (Mijn ING, Bank of Scotland, FBA, Kasbank, NIBCdirect, Staalbankiers). NIBCdirect had a gap of 6 weeks between the expiration date of their web site certificate and the login account site sparen.nibcdirect.nl in summertime of 2010.

18% of 28 internet bank web sites have not the host and domain name in their server certificate. One of these certificates with no host name was an EV certificate.

In an experiment to access the internet bank account with TLS only enabled and FIPS 140 enabled in Firefox, as advised by Mozilla for strong security measures, the negotiation to establish the se-cure connection failed e.g. with the Mijn ING bank (one is required to enable both SHA1 and MD5 hash functions for SSL3).

Conclusion and opinion:

To do an SSL/TLS configuration the right way is not that difficult, so one raises the eye

28 Feb 2010: Security advisory (medium) about the vulnerability of SSLV3 and TLS for insecure renegotiation: CVE-2009-3555. And report from Marsh Ray, “Authentication Gap in TLS Renegotiation”.

29 Already in July 2009 Randy ten Have reported the weak and sloppy security arrangements for internet banking web sites (Byte and Netwerk broadcast)..

Teus Hagen – SSL/TLS sec. in Holland NLUUG security & privacy conf. Nov 2010 V1.4 22/44

1 3

2

3

6

SSL Labs rating for internet banking

A is high, F is low

ABCDEF

brows for this branch. Any F-rating should not occur in this category. There is no excuse to allow connecting to the web site with a 40-bit cipher.

One may be excused: the security policy documents describing the requirements for this branch have been missing for this study (to be obtained from the Association of Dutch Banks?).

See for the full details the spreadsheet printout: Appendix D: spreadsheet internet banking

The category “government”

(Local) governmental web sites are there for authenti-cating access (e.g. DigiD) and for civil services (in-come tax, e-desks for governmental contracts and as-sessments, police related issues, law and order, e-court, land register, etc.). Most if not all municipal desks in Holland have an e-desk which can be ac-cessed via internet. For this category of web sites a to-tal of 26 web site assessment values have been used in the overview. The choice is not a-select, but is taken from Googling around if those sites existed.

Only 3 web sites (Rijksoverheid, municipality Bernheze) had a resp. A 88%, A 85% and A 81% rating. Not even one had a full green rating. Four out of the 27 (15%) had an SSL Labs F-rating rating score (e.g. Min. Finance, Min Health VROM, DigiD(!), Police Department of Investigation). About 23% is PCI DSS compliant. None is FIPS compliant. FIPS is recommended. Only one web site (E-court) is using an EV certificate.

The general authentication web site DigiD for providing internet access authentication for govern-mental services, allows 4 insecure encryption ciphers to be used.Too many (69%) of the governmental web sites one can use with a very weak 40-bit encryption (ex-ceptions: Belastingdienst (tax), Rijksoverheid (central government), Bernheze (community desk), DigiD (authentication; but allows insecure ciphers), and Kadaster (land registry)). One web site (Politie Rotterdam-Rijnmond) had two servers with the same URL, of which one had no HTTPS ac-tivated at all.

81% of the governmental web sites used a trusted CA. One (community desk Venray) used a cer-tificate signed by “cavenray” (CA Venray: an own invention?). One municipal desk (Horst aan de Maas) used a self signed certificate from the host provider. After a notice about this, tone has fixed this.

Conclusion and opinion:

Authentication and protection of the internet desks of the governmental organisations is probably still in a naive state. A comparison of the July figures with the figures of 31st of Oc-tober 2010 show only a very minimal change in a positive direction.

Urgent time to have a good look at the SSL/TLS configuration in operation. Urgent time to get this regulated and security policies defined and managed?

See for the full details the spreadsheet printout: Appendix E: spreadsheet governmental

Teus Hagen – SSL/TLS sec. in Holland NLUUG security & privacy conf. Nov 2010 V1.4 23/44

3

2

1 1

5

4

SSL Labs rating for gov. e-desksA is high, F is low

ABCDEF

The category “healthcare”

The category “healthcare” has web sites which provide some type of authenticated and authorized login access to e.g. centralized medical databases (EPD and related organisations), web sites of hospitals for access by medical specialists and physicians, medical institutes, state health centres (GGD), local health centres, etc. The security focus point of these web sites should be authentication and authorisation of access. The web sites with login access without using the protection of SSL/TLS have not been added to this category. The impression is that nearly all the sites in this category have enabled SSL/TLS on their web sites just by accident.

For the healthcare category 40 web sites of 34 organi-sations has been assessed. Only 11 web sites use a DV certificate. Only one (Chat Sensoor) has an EV certificate. Two web sites still use a server certificate which was expired (Sentinelzorg and one (the only protected one) of the three Careweb sites).

Half of the web sites do not provide the host/domain name on their server certificate. A bigger web site (Careweb) is using a self manufactured certificate, which is expired for more as one year. Champion is Transmoraal which server certificate is expired for more as two years. It was hard to find healthcare web sites with SSL/TLS protection.

The best security arrangements (server certificate not taken into account in this case) are with YSL, huisartsen Hogeweg, chat Welzijnsgroep, and Digipoli UMCN (only 4 out of 40 web sites). Conclusion: at least some have some idea, somehow.

While collecting the list of web sites for healthcare one notices that a majority of healthcare web sites only use the old fashioned http login facility. they do not use the SSL/TLS at all. Time to up-date the web site software. These web sites were not added to the web site list.

Conclusion and opinion:

A first look at the figures give the impression that somehow the assessments are all in error for this branch.

More investigation is probably needed. Healthcare lives and clearly has to live in an uncer-tain world.

See for the full details the spreadsheet printout: Appendix G: spreadsheet healthcare

The category “web shops”

The category “web shops” has web sites which do sales of goods (internet warehouse of e.g. books), services (e.g. internet connectivity, email handling, search for partners, etc.), assurances, consumer relations, employment agencies (e.g. Randstad), social networking services, etc. Know that e.g. Twitter, Facebook, Linkedin, etc. belong to this category.

The Dutch list of web sites assessed in this category has 48 web sites. E.g. Kwantum operate two sites with different security measures: an international one (the show case shop) and the Dutch trade web site.

Teus Hagen – SSL/TLS sec. in Holland NLUUG security & privacy conf. Nov 2010 V1.4 24/44

21

9

7

1 5

SSL Labs rating healthcare

A is high, F is low

ABCDEF

Ca 25% of the web sites had an SSL Labs A-rating : 2 (Tele2, Ziggo) from the 11 ISP web sites, nearly all assurances companies (exception was Nationale Nederlanden), only one (Wehkamp) out of 8 “internet warehouses”). Ca 23% (13 out of 48) of the web sites have an SSL Labs F-rating rating score. Ca 28% is PCI DSS compliant. And none is FIPS 140 compliant. As FIPS is especially defined for e-commerce one would expect a different figure.

Only one (ca 2%) out of 40 web sites (Wehkamp) had a full green rating. Wehkamp is the only one with an EV certificate.

6 Web sites (UPCS, Cornnet, Buitenlandse Partner, MF, “Telford”) have no way to notify their certificate is maybe revoked. At the moment of assessment for 2 sites their certificate was expired for more as one year (MF and Cornnet). Telford, the one with a localy produced certificate, is probably “just” a fishing web site (the spelling is different from the phone company Telfort).

With ca 42% of the web sites a MITM attack is possible (no secure renegotiation). Two web sites offer an insecure encryption algorithm to be used (Cornnet, Megapool). MF, Buitenlandse Partner and Cornnet use a certificate signed by an unknown CA (local, or self signed?).

With 50% of the web sites a very weak encryption (40-bit) can be used. 32 out of 48 web sites have disabled the use of the SSL2 protocol (good!).

The dutch social networking web site Hyves is a special one in this category (not a trade web site). The security arrangements are however much lower (C 45%) as their US competitors. Also the host and domain name are peculiar: using the login via http://www.hyves.nl one is redirected without any notice to https://secure.hyves.org. The secure HTTPS port on www.hyves.nl and secure.hyves.nl do not work, however the insecure (HTTP) port do work.

One comment: bof.nl (Bits of Freedom, an organisation with internet privacy and security at the top of their concerns) has a rating of A 88% rating (high) in this category. An EV certificate, which would give them a full green marking, is too expensive for this organisation. This proves that a higher rating for all the web sites in this category is easy to achieve.

11 out of the 48 web sites (23%) do not have their host/domain on their server site. 12 out of the 48 web sites (23%) use a wild card domain name. Conclusion with 46% of the web shop one is unable to check the web shop on their host/domain name.

Conclusion and opinion:

the SSL/TLS configurations of these sites could easily be improved so the general impres-sion could change within a short time frame.

Half of the web shops do not authenticate properly (no host name or a wild card).

However there is a lack of certification of these web sites for the implemented security mea-sures (see the story about lack of technical security policies requirements from the certifica-tion bodies active in this branch).

See for the full details the spreadsheet printout: Appendix F: spreadsheet web shops

Teus Hagen – SSL/TLS sec. in Holland NLUUG security & privacy conf. Nov 2010 V1.4 25/44

1 2

1

1 8

1 3

SSL Labs rating for web shops

A is high, F is low

ABCDEF

The category “academia”

The SSL Labs figures for a very small number of “academic” web sites (9 sites) have been collected: TU Delft, VU Amsterdam, TU Eindhoven, CWI, In Holland, NOVI, University of Amsterdam (UvA), and University Nijmegen. All of these academia have research and education departments which are active and influential in the internet security technical world. The web site of the academics are used for students and lecturers (lectures, agenda, private information, grading, rating, etc.).

In July only the University of Amsterdam had an A 84% SSL Labs rating. It was also the only web site with a PCI complaint configuration. With the second (re)assessment on the 31st of October also CWI showed up with a A 88% rating.

On third of the sites can be attacked with MITM tricks. Except for University of Amsterdam and CWI all allowed a cipher strength of 40-bits to be used in the encryption. Except again for UvA and CWI all allowed the SSL2 protocols to be used. Nearly all used Terena as signing CA. NOVI is us-ing an own produced server certificate.

The University of Eindhoven made it easy for themselves: the certificate had 45 Alt. Names! CWI is using a wild card for the cwi.nl domain.

Except for UvA and late comer CWI, none had a higher average SSL Labs rating for protocols, key exchange and cipher strengths than 52% (very low for this class of organisations).

Both UvA and CWI did not get a full green rating score only due to the fact that the web site al-lowed insecure renegotiation (MITM attack). An update should be possible (not simple, but it is straight forward to configure it).

Conclusion and opinion: There is no signal that the results shown here are also valid for the other academic service web sites. For all of them help to improve the web site configurations is around the corner. The real conclusion of the assessments figures for this category is left to the reader.

See for the full details the spreadsheet printout: Appendix H: spreadsheet education

The category “high technology”

In this category one will find the Dutch high-tech in-ternet organisations (certificate signing authorities (CA's), internet domain registries, consulting organisa-tions and security desks, etc.). The Foundation Internet Domain Registration for .NL domain (SIDN) is one of them. SIDN operates two sites (one for registration ac-counts and one for other type of accounts) with a dif-ferent security level. However the assessment figures should not differ much.

Ca 55% (10 out of 18; in July this figure was 33%) of the web sites have a full green rating score. 5 (ca

Teus Hagen – SSL/TLS sec. in Holland NLUUG security & privacy conf. Nov 2010 V1.4 26/44

2

23

1

SSL Labs rating for educational

A is high, F is low

ABCDEF

1 02

4

SSL Labs rating for internet sec

A is high, F is low

ABCDEF

27%) Web sites have a SSL Labs F-rating score : Cacert (a web of trust CA; has a however a high average rating of 88% but is not accredited/rusted), Perfect View Overheid (average score of 52% due to no revocation method), the SIDN home web site and since the 31st of October 2010 NLnetLabs (they use a CAcert certificate).

Quite some web sites used wild cards in their signed certificate. 56% of the web sites are suscepti-ble for a man in the middle (MITM) attack due to insecure renegotiation ability (opinion: they should know better). The SIDN general web site allowed 3 insecure cipher suites. Three web sites allowed 40-bit encryption strength (Pink Roccade (managing a CA for Dutch government) , Tunix, Perfect View Overheid).

Conclusion and opinion: NLnetLabs is on top of the rating of the web sites (protocols supported, key exchanges, ci-phers supported) just with the 31st of October 2010 assessment run. A good proof that things can be configured well.

The web sites may not be used for authentication and/or accounting purposes. So the web site reachable via HTTPS (port 443) may just be an exercising tool. The rest is left as dis-cussion food to the reader. One may not be impressed with these figures.

See for the full details the spreadsheet printout: Appendix I: spreadsheet internet security

Teus Hagen – SSL/TLS sec. in Holland NLUUG security & privacy conf. Nov 2010 V1.4 27/44

Closing remarks, conclusions and opinions

The three basic security holes and suggestions to close them:

1. Host/domain name authentication, DNSSEC: After 10 years of discussions, now the first firm step is just taken. The road is still long and too uncertain to make it succeed.

2. Owner authentication, X.509 certificates: Accreditation of authorities (CA criteria) should be organized in a proper and reliable way. Today the jurisdiction of majority of authorities is mainly just on the other end of the world. Today one cannot really rely on these certificates. The trust factor, the binding of ownership and host/domain name is uncertain and hardly there.

3. Internet security techniques, SSL/TLS configuration: security policies are unclear or mostly not defined at all. SSL/TLS configurations are doubtful, but can be made mush more secure easily on a rather short time frame.

From the results of the web sites assessments one can draw some general conclusions and opinions:

• Each category may require their own set of security measures in order to cover the end user “trust” in the web site. But do they? Policy documents to be used for the security measures are hard to find. However PCI DSS-2 and FIPS 140-2 definitions are available and could be used and applied. Strong opinion: the current security measures taken are not meeting the level that an end user may expect.

• Either the end-user should have the facility to link the required security level per different web server and/or the web server configuration should be at an expected security level at all times.

• Server certificates are used for authentication (who is at the other end). Far too many do not use a host or domain name at all or a wild card (e.g. *.example.com).

• Whenever authentication is required for a web site even HTTP (port 80) should be be secured via SSL/TLS and use HTTPS effectively.

• Web site login: use of certificates for individuals for login authentication.

• The SSL/TLS configurations are not that hard. Security can be improved considerably. With the help of some Googling a lot can be done to bring it to an acceptable level.

• The blame for failure goes too easily to the end user. e.g. his computer is hacked, left his computer unattended, used an easy to guess password, does not manage the hundreds of passwords he is forced to use, does not update his software, visited infected web sites, etc.).

• The end user is using the closed lock as his only signal for a “secure internet connection”, as well the background colour of his URL The end user has to trust this signal. As shown in this report this is not a reliable signal. Updating the SSL/TLS configurations in internet land can easily make this better, so his trust is less betrayed.

• For other applications (OpenSSH, email transport, email postbox handling, VPN) the way to improve it is a bit longer. However the tooling is there. It should be configured well.

• Put your hands on DNSSEC and secure the DNS records. Update the software to get this se-curity layer really used.

• Find a good CA or authentication tool. Make it known and build a web of trust for it so oth-ers can use this history and build trust in a cooperative way. Trust cannot be purchased.

Teus Hagen – SSL/TLS sec. in Holland NLUUG security & privacy conf. Nov 2010 V1.4 28/44

Appendix A: DNSSEC help and figures

DNSSEC Configuration help

The DNSSEC details in an extensive HowToFor DNS/DNSSEC name server configuration there is an excellent “DNSSEC HOWTO, a tutorial in disguise” written by Olaf Kolkman of NLnet Labs. This paper is merely focussed on the problems of a real DNS domain server.

The Bind9 tutorialOr use the 6 minutes tutorial (2008) on how to deploy DNSSEC in Bind9 from Alan Clegg of ISC. For small (home) network arrangements Miek Gieben (NLnet) describes the simple HowTo steps to enable DNSSEC on your local network.

The Bind9 Resolver easy stepsFor the common DNS Resolver host configuration the HowTo is described e.g. How to turn Bind9 into a validating Resolver is written by Rick van Rein (and other articles about this topic). He describes three simple steps: use Bind V9.6 or higher version (not standard in-stalled in distributions older than one year), get the DNSSEC Root key 257 (“dig  .  dsnsec” command) and check it, and if one wants to automatically track the managed-keys (from Bind V9.7) one has to install the managed-key section in the Bind configuration file: enable dnssec, make bind validating, and if possible define the managed-key section.

An intermediate Resolver solutionTo avoid the waiting time for DNSSEC to become fully available there is yet some help! DLV.ISC.org has installed a DNSSEC Look-aside Validation (DLV) Registry. If you are run-ning BIND versions 9.4.3-P2, 9.5.1-P2, 9.6.1, or a later version as your DNS resolver, you can get into DNSSEC right now. See for this your BIND DNSSEC configuration the DLV I SC help documentation . Also Unbound versions 1.1.0 and later provide support for employ-ing the DLV registry.

How to make DNSSEC it easier for you: OpenDNSSECFor routine / production use of DNSSEC, dealing with all the black magic of signing keys and key roll-overs is not an attractive job nor is it very practical. Fortunately all of this has been automated with the OpenDNSSEC tools. See for more the web site of www.OpenDNSSEC.org.

Teus Hagen – SSL/TLS sec. in Holland NLUUG security & privacy conf. Nov 2010 V1.4 29/44

Statistics: RRSIG validation requests Root server

stats.l.root-servers.org: The DNSSEC Query Types plot shows queries received for certain

DNSSEC-related query types (shown in the legend). The first-generation DNSSEC types (SIG, KEY, NXT) have been obsoleted by newer, second-generation types (DS, RRSIG, NSEC, DNSKEY).

Teus Hagen – SSL/TLS sec. in Holland NLUUG security & privacy conf. Nov 2010 V1.4 30/44

Table Resolvers of Dutch ISP's: support DNSSEC functionality

A list of 36 Dutch ISP's was collected. They operate 113 machines with a DNS resolver for their customers. Only 22 Resolvers could be tested with the “dig @ResolvingHostAddress +short test.rs.ripe.net txt” command to get more details of the functionality provided. The test.rs.ripe.net host is the host where special software was installed to do the assessment. The other Resolvers only serve their own customers so the assessment could not be run. The results show data obtained at 13th

of September 2010. DNSSEC support is still pretty young. It would be interesting to see how this evolves in time.

Teus Hagen – SSL/TLS sec. in Holland NLUUG security & privacy conf. Nov 2010 V1.4 31/44

23 Sept 2010ISP DNS sever resolver max size EDNS? DNSSEC?

64%

195.241.77.55 195.241.77.32 4096 3839 OK OK195.241.77.58 195.241.77.31 4096 3839 OK OK

Online194.134.0.97 194.134.13.72 4096 3839 OK OK194.134.5.5 194.134.13.40 4096 3839 OK OK

Xs4all194.109.6.66 194.109.20.106 512 486 NO NO194109104104 194.109.20.107 512 486 NO NO

Alice212.216.172.62 62.211.76.211 4096 1399 OK OK

208.67.222.222 208.69.35.11 512 486 NO NO208.67.220.220 208.69.35.22 512 486 NO NO

194.151.228.18 213.75.11.17 4096 3839 OK OK194.151.228.34 213.75.11.15 4096 3839 OK OK

212.54.35.25 212.54.35.233 1400 1388 OK OK212.54.40.25 212.54.41.228 1400 1388 OK OK

Demon Internet (TDNL)194.159.73.135 194.109.20.98 512 486 NO NO194.159.73.136 194.109.20.106 512 486 NO NO

195.18.114.5 195.18.114.5 4096 3839 OK OK

193.67.79.39 193.79.11.47 512 486 NO NO193.79.237.39 195.129.70.31 1412 1393 OK OK193.78.240.12 195.129.70.31 1412 1393 OK OK193.79.242.39 193.79.11.47 512 486 NO NO

12move195.241.77.53 195.241.77.36 4096 3839 OK OK195.241.77.54 195.241.77.30 4096 3839 OK OK

dig @1DNSserver +short test.rs.ripe.net txtbuf size

Telfort

OpenDNS

KPN zakelijk

Ziggo

Speeding b.v.

UUnet

Sandia DNS Visualization tool

The Sandia National Laboratory has made a DNSSEC configuration check tool DNSViz available for testing your domain. This test tool has been used to get more information about the state of valid domain names and domain names whose address binding can be trusted. The input of the test were domain names of sites who may be thought as a good reference. This recent assessment shows that much still needs to be done. It shows that the main effort to get DNS secured is just started.

The assessment date of the next table was October 2010. There is reason to believe that the values will not be different for more host names in the .NL domain.

www.cacert.org provides DNSSEC via DLV from the DNSSEC DLV service from Internet Soft-ware Consortium. A demonstration effect.

Teus Hagen – SSL/TLS sec. in Holland NLUUG security & privacy conf. Nov 2010 V1.4 32/44

2 12 2 1

2 15 3

2 15 4

1 8 2 1

1 3 4 RSA/SH A256 (5) 2

1 3 4 RSA/SH A256 (5) 2

2 3 4 RSA/SH A256 (5) 2

2 3 8 2

2 4 4 RSA/SH A256 (5) 4

2 3 7 RSA/SH A256 (8 ) 2

1 15 3 1

csrc.nist .gov

RSA/SH A1 (4) RSASH A1-N SEC3-SHA1 (3) RSA/SH A256 (2)

www.icann.org

RSA/SH A1 (2) RSASH A1-N SEC3-SHA1 (8 ) RSA/SH A256 (2)

www.isc.org

RSA/SH A1 (5) RSASH A1-N SEC3-SHA1 (4) RSA/SH A256 (2)

www.nunames.nu

RSA/SH A1 (2) RSASH A1-NSEC3-SH A1 (1) RSA/SH A256 (2)

www.abnamro.nl

www.digid.nl

www.sidn.nl

www.nlnet labs.nl RSA/SH A1 (2) RSA/SH A256 (7)

www.nluug.nl

www.surfnet .nl

www.cacert .org

RSA/SH A1 (2) RSASH A1-N SEC3-SHA1 (7) RSA/SH A256 (2)

do

ma

in

nam

e

RR

se

t s

ecu

red

RR

se

t in

se

cu

reD

NS

KE

Y/D

S/

NS

EC

s

ec

ure

dD

NS

KE

Y/D

S/

NS

EC

in

se

cu

res

ec.

alg

De

leg

at i

on

s

ecu

red

De

leg

at i

on

in

se

cu

re

Appendix B: Web shop certification and CA accreditation

Web shop “guarantee services”

The following table is a list of e-shop accreditation/ranking organisations. These organisations focus on web shop trust on a (semi) commercial base for the web shop trade. An accredited web shop is allowed to publish the logo of the accreditation organisation on its web site. All the firms in this list have been approached via email with basically two simple questions: “Is your entry in the table correct?”, and “Are there (technical) internet security policies required for your members? If so where are they published?”. Also the home pages of the e-shop accreditation organisations have been searched for any “technical security policy documents”30. None were found.

ConsuWijzer is a consumers service organisation. They provide a rating of organisations (max. rat-ing is 10) in Holland. In Holland there exists also a general Council of Accreditation. An accredita-tion organisation can obtain a certification via this council. No accreditation organisation in Holland is accepted yet. However it can be concluded from the ConsuWijzer rating figures that two organi-sations seem to apply for certification.

ICT Recht Keurmerk organisation responded to the questions that this organisation only focusses on the legal aspects for trade: the applicable law.

Conclusion: e-shop accreditation (e-shop ranking) should require technical policy documents and securi-ty measures. The arrangements should be checked periodically to see if they are in line with the requirements of the e-shop accreditation organisation.

A Google search showed that there was a discussion in 2007 within Thuiswinkel Waarborg31 (a Dutch e-shop accreditation organisation) about the technical security requirements. It is unsure if this discussion found a way into the requirements of the accreditation organisation.

There is no help from these organisations to improve the technical security aspects of web-shops.

logo E-shop accredita-tion Organisation

Consu-Wijzer rating

Council of Acceptance

Condi-tions /

policies

X.509 require-

ment

SSL/TLS config control

DNS-SEC re-quired

Thuiswinkel Waarborg

10 noweb page

weak no no

Stichting Webshop Keurmerk

10 no pdf file no no no

Bettershop.org na na pdf file no no no

Stichting Digikeur na naweb page

no no no

30 The German TUViT has made an approach to do certifications in the field of IT security (and IT quality). One is re-ferred to Certification List of TUViT.

31 Jan 2007: a web blog signals besides the legal requirements also technical requirements for certifying a web shop: “Thuiswinkel.org wil veiligheidseisen stellen “. Has there been a follow up?

Teus Hagen – SSL/TLS sec. in Holland NLUUG security & privacy conf. Nov 2010 V1.4 33/44

logo E-shop accredita-tion Organisation

Consu-Wijzer rating

Council of Acceptance

Condi-tions /

policies

X.509 require-

ment

SSL/TLS config control

DNS-SEC re-quired

Eigenaarsinfo na na no no no

Teus Hagen – SSL/TLS sec. in Holland NLUUG security & privacy conf. Nov 2010 V1.4 34/44

logo E-shop accredita-tion Organisation

Consu-Wijzer rating

Council of Acceptance

Condi-tions /

policies

X.509 require-

ment

SSL/TLS config control

DNS-SEC re-quired

Friendly Webshop na na pdf file no no no

ICT Waarborg na na pdf file no no no

ICT Recht Keurmerk

na na ? na na na

Keurmerk Veiligewegshop

na na ? no no no

MKB Keurmerk na naweb page

no no no

MKBok na na ? no no no

Q-shops na na pdf file no no no

Safe 2 Shop na naweb page

no no no

Thuiswinkel Keurmerk

na na pdf file no no no

Vereniging Veilingaankopen

na naweb page

no no no

Web Keurmerk Nederland

na na pdf file no no no

Teus Hagen – SSL/TLS sec. in Holland NLUUG security & privacy conf. Nov 2010 V1.4 35/44

List of Certficate Authorities

The following table shows the information about the Certificate Authorities which signed the cer-tificates of the assessed web sites. There are just too many different names of the CA's in the server certificates. E.g. In the certificates signed by Thawte, 9 different certificate types were found. Not all the types are “trusted” from one signing authority. The column “nr of certs” have the percentage of server certificates found with the web sites in the used list, which were signed by this CA.

The green background colour denotes an accredited CA where all certificate types are found “trust-ed”. The orange background colour denotes CA's which have not been named “trusted” by SSL Labs. Most of them use self signed server certificates.

SSL Shopper has collected a list of reviews of some of the CA's listed in this table.

Teus Hagen – SSL/TLS sec. in Holland NLUUG security & privacy conf. Nov 2010 V1.4 36/44

AAA 1% 1 100%AddT rust 3% 2 100%Akamai 1% 1 0%CAVenray 1% 1 0%CAcert 5% 4 0%Clickhere 1% 1 0%DigiCert 5% 4 50%DigiNot ar 5% 4 25%Digit alus 1% 1 0%Ent rust 1% 1 100%Equifax 4% 3 100%GT E 1% 1 100%Get ronics 3% 2 0%GlobalSign 4% 3 67%GoDaddy 2% 2 50%PPCA 3% 2 100%Plesk 1% 1 0%Posit iveSSL 3% 2 0%QuoVadis 2% 2 50%SBP1 1% 1 0%SBS 1% 1 0%St aat 4% 3 67%St art Com 2% 2 50%T erena 3% 2 0%T hawt e 12% 9 56%USERt rust 1% 1 0%UT N 5% 2 100%Xolut ion 1% 1 0%geot rust 2% 2 50%local 4% 2 0%verisign 5% 4 50%t ot als 31 31 39%

Cert i

ficat

e Au-

t horit

y ID

nr o

f cer

t s#

diff. C

ert s

% o

f tru

sted

Appendix C: SSL/TLS help and figures

List of Cipher Suites found as “supported” by the web sites.

The following table lists the cipher suites supported by the assessed Dutch web servers. The cipher strengths are provided and the weakness of the cipher suite. The last column denotes the percentage of amount of occasions the cipher suite was supported by the list of web sites.

Teus Hagen – SSL/TLS sec. in Holland NLUUG security & privacy conf. Nov 2010 V1.4 37/44

TLS_DH_anon_WITH_AES_256_CBC_SHA 256 INSEC 3 %TLS_DHE_RSA_WITH_AES_256_CBC_SHA 256 OK 45 %TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA 256 OK 2 %TLS_RSA_WITH_AES_256_CBC_SHA 256 OK 70 %TLS_DES_192_EDE3_CBC_WITH_MD5 168 OK 38 %TLS_DH_anon_WITH_3DES_EDE_CBC_SHA 168 INSEC 2 %TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA 168 OK 45 %TLS_RSA_WITH_3DES_EDE_CBC_SHA 168 OK 83 %TLS_DH_anon_WITH_AES_128_CBC_SHA 128 INSEC 3 %TLS_DH_anon_WITH_RC4_128_MD5 128 INSEC 3 %TLS_DHE_RSA_WITH_AES_128_CBC_SHA 128 OK 46 %TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA 128 OK 6 %TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA 128 OK 6 %TLS_DHE_RSA_WITH_SEED_CBC_SHA 128 OK 2 %TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA 128 OK 2 %TLS_IDEA_128_CBC_WITH_MD5 128 OK 5 %TLS_RC2_128_CBC_WITH_MD5 128 OK 35 %TLS_RC4_128_WITH_MD5 128 OK 39 %TLS_RSA_WITH_AES_128_CBC_SHA 128 OK 71 %TLS_RSA_WITH_CAMELLIA_128_CBC_SHA 128 OK 6 %TLS_RSA_WITH_CAMELLIA_256_CBC_SHA 128 OK 6 %TLS_RSA_WITH_IDEA_CBC_SHA 128 OK 5 %TLS_RSA_WITH_RC4_128_MD5 128 OK 79 %TLS_RSA_WITH_RC4_128_SHA 128 OK 83 %TLS_RSA_WITH_SEED_CBC_SHA 128 OK 2 %SSL_CK_RC4_64_WITH_MD5 64 WEAK 9 %TLS_DES_64_CBC_WITH_MD5 56 WEAK 35 %TLS_DH_anon_WITH_DES_CBC_SHA 56 INSEC 1 %TLS_DHE_RSA_WITH_DES_CBC_SHA 56 WEAK 24 %TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA 56 WEAK 20 %TLS_RSA_EXPORT1024_WITH_RC2_CBC_56_MD5 56 WEAK 8 %TLS_RSA_EXPORT1024_WITH_RC4_56_MD5 56 WEAK 11 %TLS_RSA_EXPORT1024_WITH_RC4_56_SHA 56 WEAK 20 %TLS_RSA_WITH_DES_CBC_SHA 56 WEAK 43 %TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA 40 INSEC 1 %TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 40 INSEC 1 %TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA 40 WEAK 21 %TLS_RC2_128_CBC_EXPORT40_WITH_MD5 40 WEAK 35 %TLS_RC4_128_EXPORT40_WITH_MD5 40 WEAK 35 %TLS_RSA_EXPORT_WITH_DES40_CBC_SHA 40 WEAK 30 %TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 40 WEAK 38 %TLS_RSA_EXPORT_WITH_RC4_40_MD5 40 WEAK 40 %number of cypher suit es in use 42

Cyp

her

Sui

t e

stre

ngt h

% o

f us

e

Appendix D: spreadsheet internet banking

Teus Hagen – SSL/TLS sec. in Holland NLUUG security & privacy conf. Nov 2010 V1.4 38/44

A 8 8 % T 8 5% 90% 90% N 1 24-08 -11 EV N Y Y Y N N N N Y 5 128 -256 0

A 8 5% T 8 5% 8 0% 90% N 1 15-11-10 ? N Y Y Y N Y N Y Y 8 128 -256 0

A 8 5% T 8 5% 8 0% 90% N 1 15-11-10 ? N Y Y Y N Y N Y Y 8 128 -256 0

F 8 5% U 8 5% 90% 8 0% Y - 1 30-10-11 EV N Y Y Y N Y N Y N 1 128 -128 0

A 8 1% T 8 5% 8 0% 8 0% Y 1 01-09-11 ? N Y Y Y N Y N Y Y 3 128 -168 0

F 8 1% U 8 5% 8 0% 8 0% Y 1 25-07-09 ? N Y Y Y N Y N Y N 3 128 -168 0

A 8 8 % T 8 5% 90% 90% Y 1 28 -07-11 EV N Y Y Y N Y N Y Y 8 128 -256 0

- - - - - - N 1 09-06-11 EV - - - - - - - - - - - -

B 75% T 55% 90% 8 0% Y 1 01-09-11 EV N Y Y Y Y Y N Y Y 6 128 -128 0

B 75% T 55% 90% 8 0% Y 1 01-09-11 EV N Y Y Y Y Y N Y Y 6 128 -128 0

F 8 8 % U 8 5% 90% 90% N - 1 12-03-11 ? N Y Y Y N N N N N 10 128 -256 0

A 8 5% T 8 5% 8 0% 90% N 1 11-03-12 DV N Y Y Y N Y N N Y 5 128 -256 0

A 8 5% T 8 5% 8 0% 90% Y 1 10-07-11 ? N Y Y Y N N N Y Y 4 128 -256 0

F 48 % U 55% 40% 50% N - 1 21-08 -10 ? N Y Y Y Y Y N Y N 14 40-168 8

A 8 8 % T 8 5% 90% 90% N 1 12-01-11 ? N Y Y Y N Y N N Y 5 128 -256 0

A 8 8 % T 8 5% 90% 90% N 1 12-01-11 ? N Y Y Y N Y N N Y 5 128 -256 0

ideal C 52% T 55% 40% 60% N 2 26-06-13 ?

A 8 4% T 8 5% 90% 8 0% Y 1 21-04-11 EV N Y Y Y N Y N Y Y 2 128 -128 0

F 75% U 55% 8 0% 90% N - 1 21-04-11 AAA ? N Y Y Y Y Y N Y N 9 128 -256 0

- - - - - - N - - - - - - - - - - - - - - - - -

A 8 8 % T 8 5% 90% 90% Y 1 19-09-11 EV N Y Y Y N Y N Y Y 8 128 -256 0

A 8 8 % T 8 5% 90% 90% Y 1 12-08 -11 EV N Y Y Y N Y N Y Y 5 128 -256 0

- - - - - - N 1 07-09-11 EV - - - - - - - - - - - -

F 61% U 8 5% 40% 60% Y - 1 02-09-11 ? N Y Y Y N Y N Y N 9 40-256 4

C 52% T 55% 40% 60% N 2 25-01-11 SBS DV N Y Y Y Y Y N Y N 15 40-256 7

C 52% T 55% 40% 60% N 1 06-01-11 DV N Y Y Y Y Y N Y N 21 40-256 10

A 8 1% T 8 5% 8 0% 8 0% Y 1 01-09-11 ? N Y Y Y N Y N Y Y 1 128 -128 0

T OT ALS 2 7 2 4 7 7 % 7 5% 7 6% 7 6% 80% 4 4 % 5 2 DV+EV 4 8% 0% 1 00% 1 00% 1 00% 2 6% 87 % 0% 7 8% 65% 7 1 7 %EV 37 %

internetbankieren.fries-landbank

internetbankieren.friesland-bank.nl /194.151.192.18 2

internetbankieren.fries-landbank.nl Verisign

mijnbankzaken.gilissen mijnbankzaken.gilissen.nl /2.190.205.77 mijnbankzaken.gilissen.nl Thawte

mijnbankzaken.gilissenmijnbankzaken.gilissen.nl /0.255.163.28 mijnbankzaken.gilissen.nl Thawte

mijning mijning.nl /145.221.55.11 Verisign

mijn.postbank mijn.postbank.nl /5.221.55.1 mijn.postbank.nl Verisign

mijn.postbank mijn.postbank.nl /5.221.55.2 www.mijn.postbank.nl Thawte

abnamrowww.abnamro.nl /167.202.214.30 www.abnamro.nl Verisign

asnbankwww.asnbank.nl /194.151.220.8 0 www.asnbank.nl Verisign

atbank www.atbank.nl /3.172.165.232 www.atbank.nl Verisign

atbankwww.atbank.nl /7.242.117.56 www.atbank.nl Verisign

bankofscotland www.bankofscotland.nl /212.34.64.169 Verisign

direktbankwww.direktbank.nl /8 2.94.228 .226 www.direktbank.nl Equifax

dnb www.dnb.nl /195.193.90.8 *.dnb.nl Thawte

fba www.fba.nl /8 0.79.193.70 Verisign

fortisbank www.fortisbank.nl /4.140.33.6 www.fortisbank.nl Verisign

fortisbank www.fortisbank.nl /4.140.41.6 www.fortisbank.nl Verisign

www.ideal.nl /79.170.95.18 4 www.ideal.nl DigiCert

ing www.ing.nl /195.248 .8 7.18 8 www.ing.nl Verisign

kasbank www.kasbank.nl /213.171.132.155

nibcdirectwww.nibcdirect.nl /93.94.227.72

sparen.nibcdirectsparen.nibcdirect.nl /95.142.103.132 sparen.nibcdirect.nl Verisign

rabobankwww.rabobank.nl /145.72.70.20 www.rabobank.nl Verisign

snsbankwww.snsbank.nl /194.151.220.72 www.snsbank.nl Verisign

staalbankierswww.staalbankiers.nl /62.58 .8 2.137 Verisign

triodoswww.triodos.nl /8 5.158 .166.108 www.triodos.nl

vermogensbeheeronlinewww.vermogensbeheeronline.nl /212.72.37.147

www.vermogensbe-heeronline.nl Thawte

wu-adviseurwww.wu-adviseur.nl /145.221.96.19 www.wu-adviseur.nl Verisign

Org

an

i-s

ati

on

id

enti

fier

ww

w

sit

e

La

bs

ra

tin

ga

v. r

ati

ng

CA

tru

ste

dp

roto

col

key

exch

an

ge

cip

her

s

MIT

M?

CN

on

ce

rtif

ica

te

#Alt

na

mes

cert

va

lid

u

nti

l

cert

CA

cer t

typ

eT

LS

1.1

TL

S 1

.0

SS

L 3

.0

SS

L 2

.0+

SS

L 2

.0

ses

sio

n

res

um

pti

on

str

ict

tra

ns

po

rtin

sec

ure

re

neg

.

PC

I

#cyp

her

scy

ph

er

ran

ge

#wea

k cy

ph

s

Appendix E: spreadsheet governmental

Teus Hagen – SSL/TLS sec. in Holland NLUUG security & privacy conf. Nov 2010 V1.4 39/44

B 79% T 55% 90% 90% Y 1 13-10-13 Y ? N Y Y Y Y Y N 9 128 -256 0 0

C 52% T 55% 40% 60% Y 2 01-10-11 Y UTN ? N Y Y Y Y N N 15 40-256 7 0

C 52% T 55% 40% 60% N 1 11-09-12 Y ? N Y Y Y Y N N 20 40-256 12 0

A 8 8 % T 8 5% 90% 90% N 2 17-03-13 Y UTN ? N Y N Y Y Y N 4 128 -256 0 0

- - - - - - N - - - - - - - - - - - - - - - - -

F 51% U 55% 40% 60% N - 1 13-12-10 Y ? N Y Y Y Y N N 21 40-256 10 0

C 52% T 55% 40% 60% Y 2 07-11-11 Y ? N Y Y Y Y N N 25 40-256 14 0

D 48 % T 55% 40% 50% Y 1 22-10-12 Y ? N Y Y Y Y N N 14 40-168 8 0

A 8 5% T 8 5% 8 0% 90% Y 1 19-04-12 Y ? N Y N N Y Y N 12 128 -256 0 0

C 52% T 55% 40% 60% N 1 23-07-11 Y ? N Y Y Y Y N N 15 40-256 7 0

D 48 % T 55% 40% 50% N 1 19-06-11 Y ? N Y Y Y Y N N 14 40-168 8 0

C 57% T 8 5% 40% 50% N 1 18 -04-13 Y ? N Y N Y N N N 11 40-168 5 0

D 48 % T 55% 40% 50% N 1 16-03-13 Y ? N Y Y Y Y N N 14 40-168 8 0

C 61% T 8 5% 40% 60% Y 1 18 -02-11 Y ? N Y N Y Y N N 18 40-256 10 0

F 48 % U 55% 40% 50% Y - 1 29-05-13 Y ? Y Y Y Y N N 14 40-168 8 0

C 57% T 8 5% 40% 50% N 1 19-12-10 Y ? N Y N Y N N N 11 40-168 5 0

C 52% T 55% 40% 60% Y 1 08 -01-11 Y DV N Y Y Y Y N N 20 40-256 9 0

F 58 % T 8 5% 0% 90% N 1 16-05-11 Y ? N Y N N N Y N 12 128 -256 0 4

A 8 1% T 8 5% 8 0% 8 0% N 1 01-05-12 Y ? N Y N Y N Y N 2 128 -168 0 0

e-courtC 52% T 55% 40% 60% Y 1 04-01-11 Y EV N Y Y Y Y N N 20 40-256 9 0

B 72% T 55% 8 0% 8 0% N 1 23-09-12 Y ? N Y Y Y Y Y N 6 128 -168 0 0

D 48 % T 55% 40% 50% N 2 21-03-12 Y UTN ? N Y Y Y Y N N 14 40-168 8 0

- - - - - - N - - - - - - - - - - - - - - - - -

C 52% T 55% 40% 60% Y 1 06-10-11 Y DV N Y Y Y Y N N 21 40-256 10 0

C 52% T 55% 40% 60% N 1 29-05-11 Y ? 20 40-256

F 51% U 55% 40% 60% N - 1 26-12-08 Y UTN ? ? Y Y Y Y N N 25 40-256 14 0

D 48 % T 55% 40% 50% N 1 15-07-13 Y ? N Y Y Y N N N 14 40-168 8 0

T OT ALS 2 7 2 5 58% 88% 63% 4 7 % 63% 37 % 3 1 1 00% DV+EV 1 1 % 0% 1 00% 7 1 % 92 % 7 9% 2 5% 0% 2 1 7 5% 4 %

EV 4 %

mijn.belastingdienstmijn.belastingdienst.nl /8 5.159.96.8 4 mijn.belastingdienst.nl Verisign

minf inwww.minf in.nl /77.245.91.76 www.minf in.nl

overheidwww.overheid.nl /62.112.232.27 www.overheid.nl DigiN otar

rijksoverheidwww.rijksoverheid.nl /77.245.92.62 *.rijksoverheid.nl

vromwww.vrom.nl /77.245.92.64

almere almere.nl /62.112.236.253 Thawte

eemsmond.digitalebalieeemsmond.digitalebalie.nl /8 0.95.160.78 *.digitalebalie.nl geotrust

pki.enkhuizenpki.enkhuizen.nl /8 0.79.99.15 pki.enkhuizen.nl Getronics

secure.bernhezesecure.bernheze.org /91.200.50.120 secure.bernheze.org Getronics

amsterdam www.amsterdam.nl /62.112.234.12 www.amsterdam.nl Thawte

balie.delf twww.balie.delft.nl /145.32.101.22 balie.delf t.nl Getronics

horstaandemaashorstaandemaas.nl /8 9.250.176.93 www.horstaandemaas.nl Getronics

nijmegen www.nijmegen.nl /217.149.193.192 www.nijmegen.nl DigiN otar

utrechtwww.utrecht.nl /195.193.167.120 www.utrecht.nl Verisign

venraywww.venray.nl /212.203.22.98 CAVenray

wageningen www.wageningen.nl /8 0.113.166.193 www.wageningen.nl DigiN otar

actisjurawww.actisjura.nl /195.242.98 .162 www.actisjura.nl Equifax

digidwww.digid.nl /212.159.196.171 www.digid.nl DigiN otar

diginotarwww.diginotar.nl /62.58 .36.118 www.diginotar.nl DigiN otarwww.e-court.nl /91.18 4.6.238 www.e-court.nl Thawte

kadasterkadaster.nl /145.77.103.19 www.kadaster.nl getronics

Politie-rotterdam-rijnmond www.politie-rotterdam-rijn-mond.nl /9.70.8 .135

www.politie-rotterdam-rijn-mond.nl

Politie-rotterdam-rijnmondwww.politie-rotterdam-rijn-mond.nl /5.101.166.3

politie-amsterdam-am-stelland

www.politie-amsterdam-amstelland.nl /217.170.16.157

www.politie-amsterdam-amstel-land.nl Thawte

politiewww.politie.nl /62.112.225.193 www.politie.nl Thawte

politieonderzoekenwww.politieonderzoeken.nl /8 2.150.140.64

zoek.off icielebekend-makingen

www.zoek.of f icielebek-endmakingen.nl /62.112.237.90

zoek.of f icielebekendmakin-gen.nl DigiN otar

Org

an

i-s

ati

on

id

enti

fier

ww

w

sit

e

La

bs

ra

tin

ga

v. r

ati

ng

CA

tru

ste

dp

roto

col

key

exch

an

ge

cip

her

s

MIT

M?

CN

on

ce

rtif

ica

te

#Alt

na

mes

cert

va

lid

u

nti

l

RS

A S

HA

1 s

ig

cert

CA

cer t

typ

ere

voca

ted

?T

LS

1.0

SS

L 2

.0

ses

sio

n

res

um

pti

on

ins

ecu

re

ren

eg.

PC

I

FIP

S r

ead

y#c

yph

ers

cyp

her

ra

ng

e

#wea

k cy

ph

s#i

ns

ec

cyp

hs

Appendix F: spreadsheet web shops

Teus Hagen – SSL/TLS sec. in Holland NLUUG security & privacy conf. Nov 2010 V1.4 40/44

F 51% U 55% 40% 60% Y - 1 30-04-35 local ? N Y Y Y Y Y N Y N N 22 40-256 11 0

A 8 5% T 8 5% 8 0% 90% N 2 06-08 -13 UTN ? 2 Y Y Y N Y N Y Y N 13 128 -256 0 0

A 8 5% T 8 5% 8 0% 90% N 2 15-04-11 UTN ? 2 Y Y Y N Y N Y Y N 13 128 -256 0 0

C 61% T 8 5% 40% 60% N 1 24-06-12 ? 2 Y Y Y N N N N N N 11 40-256 6 0

F 61% U 8 5% 40% 60% N - 1 28 -07-11 ? N Y Y Y N Y N Y N N 14 40-256 6 0

C 61% T 8 5% 40% 60% N 2 21-02-12 ? 2 Y Y Y N Y N N N N 14 40-256 6 0

service.xs4all C 52% T 55% 40% 60% Y 2 22-09-16 DV 1 Y Y Y Y Y N Y N N 23 40-256 10 0

se.tele2 se.tele2.nl /193.12.93.164 A 8 4% T 8 5% 90% 8 0% Y se.tele2.nl 2 10-05-12 UTN ? 2 Y Y Y N Y N Y Y N 1 128 -128 0 0

C 61% T 8 5% 40% 60% N 1 09-03-12 ? 2 Y Y Y N N N N N N 11 40-256 6 0

webmail.xs4all C 52% T 55% 40% 60% Y 2 22-09-16 DV 1 Y Y Y Y Y N Y N N 22 40-256 9 0

F 75% U 8 5% 8 0% 60% N - 1 10-09-08 local ? N Y Y Y N Y N Y N N 10 56-256 2 0

F 48 % T 8 5% 0% 60% Y 1 20-12-12 DV 1 Y Y Y N Y N Y N N 25 40-256 10 7

A 8 5% T 8 5% 8 0% 90% Y 1 10-04-11 UTN ? 2 Y Y Y N Y N Y Y N 8 128 -256 0 0

C 52% T 55% 40% 60% N 1 10-04-11 UTN ? 2 Y Y Y Y Y N Y N N 20 40-256 9 0

F 8 5% U 8 5% 8 0% 90% N - 1 10-09-20 SBP1 ? N Y Y Y N Y N Y N N 8 128 -256 0 0

A 8 5% T 8 5% 8 0% 90% Y 1 18 -05-11 ? 2 Y Y Y N Y N Y Y N 5 128 -256 0 0

- - - - - - N - - - - - - - - - - - - - - - - - - -

F 8 5% U 8 5% 8 0% 90% N - 1 10-09-20 SBP1 ? N Y Y Y N Y N Y N N 8 128 -256 0 0

A 8 5% T 8 5% 8 0% 90% Y 1 18 -05-11 ? 2 Y Y Y N Y N Y Y N 5 128 -256 0 0

- - - - - - N - - - - - - - - - - - - - - - - - - -

C 52% T 55% 40% 60% N 1 07-09-11 ? 1 Y Y Y Y Y N Y N N 17 40-256 7 0

F 75% U 8 5% 8 0% 60% N - 1 04-01-12 CAcert ? 1 Y Y Y N Y N Y N N 10 56-256 2 0

A 8 8 % T 8 5% 90% 90% N 1 16-10-12 DV 1 Y Y Y N Y N N Y N 8 128 -256 0 0

C 52% T 55% 40% 60% N 1 11-01-11 ? 2 Y Y Y Y Y N Y N N 20 40-256 9 0

C 52% T 55% 40% 60% Y 1 18 -12-10 ? 2 20 40-256

B 76% T 55% 8 0% 90% N 2 08 -02-13 UTN ? 2 Y Y Y Y Y N Y Y N 9 128 -256 0 0

telfordwww.telford.nl /91.198 .106.32

telfortwww.telfort.nl /1.173.34.225 *.telfort.nl

telfortwww.telfort.nl /1.173.34.237 telfort.nl

netmail.hetnetnetmail.hetnet.nl /213.75.8 .41 netmail.hetnet.nl Verisign

service.upcsservice.upcs.nl /93.18 8 .250.13 Xolution

serviceweb.solconserviceweb.solcon.nl /212.45.32.175 *.solcon.nl DigiCertservice.xs4all.nl /194.109.6.121 *.xs4all.nl Equifax

webmail.kpnmailwebmail.kpnmail.nl /213.75.8 .47 webmail.kpnmail.nl Verisignwebmail.xs4all.nl /194.109.6.100 *.xs4all.nl Equifax

cornnetwww.cornnet.nl /95.211.113.225

upcwww.upc.nl /213.46.242.101 www.upc.nl Equifax

z iggo www.z iggo.nl /2.54.32.18 *.z iggo.nl

z iggo www.z iggo.nl /2.54.32.19 *.z iggo.nl

buitenlandsepartnerwww.buitenlandsepartner.nl /91.195.201.71

parship www.parship.nl /213.198 .8 5.74 *.parship.nl Thawte

relatieplanetwww.relatieplanet.nl /8 5.17.248 .190

buitenlandsepartnerwww.buitenlandsepartner.nl /91.195.201.71

parship www.parship.nl /213.198 .8 5.74 *.parship.nl Thawte

relatieplanetwww.relatieplanet.nl /8 5.17.248 .190

candidate.manpower candidate.manpower.com /96.16.245.176 *.manpower.com Akamai

atcomputing www.atcomputing.nl /8 0.113.6.236

bof www.bof.nl /213.8 4.134.2 www.bof.nl Equifax

consumentenbondwww.consumentenbond.nl /8 5.158 .166.40 www.consumentenbond.nl Thawte

e-f lexerwww.e-f lexer.nl /194.54.145.5 www.e-flexer.nl Thawte

kwantum www.kwantum.nl /77.242.124.68 www.kwantum.nl

Org

an

i-s

ati

on

id

enti

fier

ww

w

sit

e

La

bs

ra

tin

ga

v. r

ati

ng

CA

tru

ste

dp

roto

col

key

exch

an

ge

cip

her

s

MIT

M?

CN

on

ce

rtif

ica

te

#Alt

na

mes

cert

va

lid

u

nti

l

cert

CA

cer t

ty

pere

voca

tio

n

met

ho

dTL

S 1

.0

SS

L 3

.0

SS

L 2

.0+

SS

L 2

.0

ses

sio

n

res

um

pti

on

str

ict

tra

ns

po

rtin

sec

ure

re

neg

.P

CI

FIP

S r

ead

y#c

yph

ers

cyp

her

ra

ng

e

#wea

k cy

ph

s#i

ns

ec

cyp

hs

Teus Hagen – SSL/TLS sec. in Holland NLUUG security & privacy conf. Nov 2010 V1.4 41/44

F 75% U 8 5% 8 0% 60% N - 1 16-03-09 ? N Y Y Y N N Y N N 10 56-256 2 0

C 52% T 55% 40% 60% N 1 23-04-12 DV 1 Y Y Y Y Y N N N N 20 40-256 9 0

C 52% T 55% 40% 60% Y 2 23-04-13 ? 2 Y Y Y Y Y N Y N N 15 40-256 7 0

C 52% T 55% 40% 60% Y 2 27-06-11 DV 1 Y Y Y Y N N Y N N 17 40-256 8 0

A 8 5% T 8 5% 8 0% 90% N 1 31-07-11 ? 2 Y Y Y N Y N N Y N 8 128 -256 0 0

C 52% T 55% 40% 60% Y 1 05-06-12 DV 2 14 40-256

A 8 5% T 8 5% 8 0% 90% Y 1 19-06-11 ? 2 Y Y Y N N Y Y N 6 128 -256 0 0

F 51% U 55% 40% 60% Y - 2 16-03-12 ? 2 Y Y Y Y N Y N N 25 40-256 14 0

C 52% T 55% 40% 60% N 1 10-12-11 DV 2 Y Y Y Y N Y N N 20 40-256 9 0

F 58 % U 8 5% 40% 50% N - 2 08 -02-13 UTN ? 2 Y Y Y N N N N N 8 40-168 5 0

F 8 5% U 8 5% 8 0% 90% N - 1 10-11-11 DV 1 Y Y Y N N N N N 8 128 -256 0 0

F 48 % T 8 5% 0% 60% Y 2 25-02-11 ? 2 Y Y Y N Y N Y N N 29 40-256 9 7

F 8 8 % U 8 5% 90% 90% N - 2 13-03-15 DV 2 Y Y Y N N N Y N N 7 128 -256 0 0

neckA 8 5% T 8 5% 8 0% 90% Y 1 10-03-12 ? 2 Y Y Y N Y N Y Y N 8 128 -256 0 0

- - - - - - N - - - - - - - - - - - - - - - - - - -

C 61% T 8 5% 40% 60% N 1 21-04-11 ? 2 Y Y Y N N N N N N 11 40-256 6 0

- - - - - - N - - - - - - - - - - - - - - - - - - -

C 52% T 55% 40% 60% Y 1 02-07-11 ? 2 Y Y Y Y Y N Y N N 20 40-256 9 0

A 8 1% T 8 5% 8 0% 8 0% N 2 25-06-11 UTN ? 2 Y Y Y N Y N Y Y N 1 168 -168 0 0

A 8 8 % T 8 5% 90% 90% Y 1 30-04-12 EV 2 Y Y Y N N N Y Y N 8 128 -256 0 0

C 52% T 55% 40% 60% Y 1 14-06-12 ? 2 Y Y Y Y Y N Y N N 25 40-256 8 0

C 52% T 55% 40% 60% Y 1 14-06-12 ? 2 Y Y Y Y Y N Y N N 25 40-256 8 0

T OT ALS 4 8 4 4 69% 7 6% 7 3% 57 % 7 1 % 4 2 % 1 1 2 DV+EV 2 3% 1 00% 1 00% 1 00% 36% 83% 0% 7 9% 31 % 0% 2 8 60% 5%EV 2 %

mf www.mf.nl /193.138 .158 .8 8 Digitalus

mijnalbumwww.mijnalbum.nl /8 3.149.8 8 .122 *.mijnalbum.nl Equifax

randstadwww.randstad.nl /194.151.98 .177 *.randstad.nl DigiCert

schoolbankwww.schoolbank.nl /62.69.178 .207 *.schoolbank.nl Equifax

centraalbeheerwww.centraalbeheer.nl /213.214.114.30 www.centraalbeheer.nl Verisign

coolbluewww.coolblue.nl /8 0.95.168 .33 www.coolblue.nl Thawte

fbtowww.fbto.nl /145.219.10.78 www.fbto.nl Verisign

horecawebshopwww.horecawebshop.com /8 7.233.151.54 DigiCert

internetshopwww.internetshop.nl /217.26.125.73 www.internetshop.nl Thawte

kwantumwww.kwantum.com /213.201.239.8 6

lexawww.lexa.nl /62.23.30.4 Equifax

megapoolwww.megapool.nl /212.178 .101.126 www.megapool.nl USERtrust

neckermanwww.neckerman.com /66.170.1.110 GoDaddywww.neck.nl /195.18 9.244.14 www.neck.nl Verisign

nnwww.nn.nl /3.75.28 .140

nn www.nn.nl /3.75.8 .33 www.nn.nl Verisign

pixmaniawww.pixmania.com /77.75.49.199

ttec www.ttec.nl /153.94.51.8 www.ttec.nl Thawte

univewww.unive.nl /195.42.134.165 www.unive.nl

wehkampwww.wehkamp.nl /194.151.96.141 www.wehkamp.nl Verisign

secure.hyvessecure.hyves.org /4.100.116.214 secure.hyves.org Thawte

secure.hyvessecure.hyves.org /4.100.119.7 secure.hyves.org Thawte

Org

an

i-s

ati

on

id

enti

fier

ww

w

sit

e

La

bs

ra

tin

ga

v. r

ati

ng

CA

tru

ste

dp

roto

col

key

exch

an

ge

cip

her

s

MIT

M?

CN

on

ce

rtif

ica

te

#Alt

na

mes

cert

va

lid

u

nti

l

cert

CA

cert

typ

ere

voca

tio

n

met

ho

dT

LS

1.0

SS

L 3

.0

SS

L 2

.0+

SS

L 2

.0

ses

sio

n

res

um

pti

on

str

ict

tra

ns

po

rtin

sec

ure

re

neg

.P

CI

FIP

S r

ead

y#c

yph

ers

cyp

her

ra

ng

e

#wea

k cy

ph

s#i

ns

ec

cyp

hs

Appendix G: spreadsheet healthcare

Teus Hagen – SSL/TLS sec. in Holland NLUUG security & privacy conf. Nov 2010 V1.4 42/44

- - - - - - N - 2 05-03-11 UTN ? 2 - - - - - - - - - - - - -

- - - - - - N - 0 - - - - - - - - - - - - - - - - -

- - - - - - N - 0 - - - - - - - - - - - - - - - - -

F 78 % U 55% 90% 90% N - 1 12-08 -09 ? N Y Y Y Y - Y N Y N N 7 128 -256 0

F 75% U 55% 8 0% 90% N - 1 07-02-12 DV 1 Y Y Y Y Y N Y N N 9 128 -256 0

D 48 % T 55% 40% 50% N 1 08 -10-12 DV 1 Y Y Y Y Y N N N N 9 128 -256 0

F 38 % T 55% 0% 60% N 2 24-04-11 UTN ? 2 Y Y Y Y Y N N N N 27 40-256 9

C 61% T 8 5% 40% 60% N 2 12-06-11 EV 2 Y Y Y N - Y N N N N 12 40-256 4

- - - - - - N - - - - - - - - - - - - - - - - - - -

A 8 8 % T 8 5% 90% 90% N 1 15-09-11 ? 2 Y Y Y N - Y N N Y N 8 128 -256 0

A 8 5% T 8 5% 8 0% 90% Y 1 06-08 -12 ? 2 Y Y Y N Y N Y Y N 8 128 -256 0

C 52% T 55% 40% 60% N 2 29-10-11 UTN ? 2 Y Y Y Y Y N Y N N 20 40-256 9

B 79% T 55% 90% 90% N 2 27-04-11 ? 2 Y Y Y Y Y N N Y N 9 128 -256 0

D 48 % T 55% 40% 50% N 2 19-11-11 DV 1 Y Y Y Y Y N N N N 14 40-168 8

D 48 % T 55% 40% 50% N 1 08 -09-11 DV 1 Y Y Y Y Y N Y N N 14 40-168 8

C 52% T 55% 40% 60% Y 2 09-12-10 AAA ? 2 Y Y Y Y Y N Y N N 22 40-256 9

C 61% T 8 5% 40% 60% Y 2 25-09-11 ? 1 Y Y Y N N N Y N N 16 40-256 8

C 61% T 8 5% 40% 60% N 1 06-02-11 DV 2 Y Y Y N - Y N N N N 12 40-256 4

C 52% T 55% 40% 60% Y 2 08 -11-12 AAA ? 2 Y Y Y Y Y N Y N N 20 40-256 9

C 61% T 8 5% 40% 60% N 2 17-10-11 UTN ? 2 Y Y Y N exedded05.mainserver.nl Y N Y N N 20 40-256 9

D 48 % T 55% 40% 50% N 1 17-09-11 DV 2 Y Y Y Y Y N Y N N 14 40-168 8

F 51% U 55% 40% 60% N - 4 02-06-11 UTN ? 2 Y Y Y Y - N N Y N N 20 40-256 9

D 48 % T 55% 40% 50% N 1 23-03-12 ? 2 Y Y Y Y Y N Y N N 14 40-168 8

D 48 % T 55% 40% 50% N 1 08 -10-12 DV 1 Y Y Y Y Y N N N N 14 40-168 8

F 48 % U 55% 40% 50% N - 2 05-03-11 UTN ? 2 Y Y Y Y - Y N N N N 14 40-168 8

C 52% T 55% 40% 60% N 2 25-02-11 DV 2 Y Y Y Y 23.tidi.nl Y N N N N 20 40-256 9

F 48 % U 55% 40% 50% N - 2 19-10-12 UTN ? 2 Y Y Y Y - Y N N N N 14 40-168 8

F 51% U 55% 40% 60% N - 1 02-11-12 ? 2 Y Y Y Y Y N Y N N 20 40-256 9

F 8 5% U 8 5% 8 0% 90% N - 1 22-06-11 DV 1 Y Y Y N web165.extendcp.co.uk Y N Y N N 4 168 -256 0

acute-hulp.gezond.ams-terdam

www.acutehulp.gezond.ams-terdam.nl /194.109.216.131

carewebwww.careweb.nl /6.98 .141.250

careweb www.careweb.nl /9.72.142.98

carewebwww.careweb.nl /7.233.18 9.98 Plesk

cohesie www.cohesie.org /8 9.20.92.27 Equifax midas-www.systemec.nl

cwzwww.cwz .nl /194.105.128 .148

f lexwerkers.hol-landzorg.nl Equifax

host-8 4-241-133-143.dsl.introweb.nl

behandel ing.-jel l inekcl inics

behandeling.jellinekclinics.com /8 5.158 .206.48 *.jellinekclinics.com

wildcard.jellinekclinics.-com-live1.lemon.cyso.net

chat.sensoor chat.sensoor.nl /2.94.173.175 chat.sensoor.nl comodo

chat.sensoor chat.sensoor.nl /2.94.18 1.247

chat.welzi jnsgroepchat.welz ijnsgroep.nl /8 2.94.173.166

chat.welz ijns-groep.nl Thawte

digipol i .extern.um-cn

digipoli.extern.umcn.nl /131.174.165.73

digipoli.extern.umc-n.nl uz i digipoli.extern.umcn.nl

mijn.interapy mijn.interapy.nl /93.92.98 .99 *.interapy.nlstaging1.interapy.intermax.nl

webzorg.e-behan-del ing

webzorg.e-behandeling.nl /193.46.47.100 *.e-behandeling.nl certum

ip-193.46.47.100.static.crowley.pl

alcoholdebaaswww.alcoholdebaas.nl /91.206.136.2 *.alcoholdebaas.nl Equifax www.alcoholdebaas.nl

chatf onewww.chatfone.nl /8 7.249.103.30 *.chatfone.nl Equifax

rev-30.103.249.8 7.virtu.nl

gr ipopjedipwww.gripopjedip.nl /212.79.224.47 www.gripopjedip.nl gripopjedip.nl

huisartsenwww.huisartsen.nl /8 0.95.169.161 *.huisartsen.nl geotrust

msd-huisartsen.inter-max.nl

hulpmixwww.hulpmix.nl /8 2.94.173.168 www.hulpmix.nl Thawte

maatschappel i jkw-erkonl ine

www.maatschappelijkwerkon-line.nl /8 5.17.171.35

www.maatschap-pelijkwerkonline.nl www-1.kwadraad.net

prakti jkinf owww.praktijkinfo.nl /8 5.158 .254.195 www.praktijkinfo.nl

pratenonl inewww.pratenonline.nl /62.50.23.201 www.pratenonline.nl Thawte

62-50-23-201.amst2.eu.psigh.com

surv iv alkidxlwww.survivalkidxl.nl /217.148 .90.110

v irenze-internet-therapie

www.virenze-internettherapie.nl /193.172.235.18 7

www.virenze-inter-nettherapie.nl Thawte www.annazorg.motiv.nl

f lexwerkers.hol -landzorg

f lexwerkers.hollandzorg.nl /8 4.241.133.143

f lexwerkers.hol-landzorg.nl Equifax

host-8 4-241-133-143.dsl.introweb.nl

ggdr iv ierenlandwww.ggdrivierenland.nl /194.109.216.131

ggdzeelandwww.ggdzeeland.nl /212.115.203.23 www.ggdzeeland.nl PositiveSSL

har tenv aatgroepwww.hartenvaatgroep.nl /194.109.216.135

hdt-oost www.hdt-oost.nl /195.20.9.8 2 Thawte danny.eatserver.nl

huisartsenhogewegwww.huisartsenhogeweg.nl /79.170.40.165 Equifax

Org

an

i-sa

t io

n

ide

nt i

fie

r

ww

w s

ite

Lab

s r

at i

ngav

. ra

t in

g

CA

tru

st e

dp

rot o

co

l

key

e

xc

han

ge

cip

her

s

MIT

M?

CN

on

cert

ific

ate

#A

lt n

am

es

cert

va

lid

un

t il

cert

CA

cert

typ

ere

vo

ca

t io

n m

eth

od

TLS

1.0

SS

L 3

.0

SS

L 2

.0+

SS

L 2

.0

se

rver

ho

st

na

me

se

ss

ion

re

su

mp

t io

nst

ric

t t r

ans

po

rtin

sec

ure

re

ne

g.

PC

I

FIP

S r

ea

dy

#cy

ph

ers

cyp

he

r ra

ng

e

#w

eak

c

yp

hs

Appendix H: spreadsheet education

Teus Hagen – SSL/TLS sec. in Holland NLUUG security & privacy conf. Nov 2010 V1.4 43/44

intranet.tudelf t C 52% T 55% 40% 60% Y intranet.tudelf t.nl 1 02-02-13 Terena ? N Y Y Y Y Y N Y N N 20 40-256 9 0

mijn.vu D 48 % T 55% 40% 50% N mijn.vu.nl 2 06-01-13 Terena ? N Y Y Y Y Y N N N N 14 40-168 8 0

w3.tue w3.tue.nl /131.155.2.51 C 52% T 55% 40% 60% N apache.tue.nl 45 21-10-12 Terena ? N Y Y Y Y Y N N N N 24 40-256 9 0

cwiA 8 8 % T 8 5% 90% 90% N *.cwi.nl 2 21-06-15 UTN ? N Y Y Y N Y N Y Y N 7 128 -256 0 0

inholland D 48 % T 55% 40% 50% Y www.inholland.nl 1 17-11-12 Terena ? N Y Y Y Y Y N Y N N 14 40-168 8 0

inholland - - - - - - N - - - - - - -

medewerker.uva A 8 4% T 8 5% 90% 8 0% Y medewerker.uva.nl 2 13-09-12 Terena ? N Y Y Y N Y N Y Y N 1 128 -128 0 0

novi F 51% U 55% 40% 60% N - 1 07-08 -37 local ? N Y Y Y Y Y N N N N 20 40-256 9 0

radboudnetD 48 % T 55% 40% 50% N www.ru.nl 16 22-09-13 Terena ? N Y Y Y Y Y N Y N N 14 40-168 8 0

TOTALS 9 8 59% 8 8 % 63% 53% 63% 33% 1 0 DV+EV 0% 0% 1 00% 1 00% 1 00% 7 5% 1 00% 0% 63% 2 5% 0% 7 7 5% 0%

EV 0%

intranet.tudelf t.nl /131.18 0.77.17mijn.vu.nl /130.37.240.138

www.cwi.nl /192.16.191.43www.inholland.nl /4.171.35.40www.inholland.nl /4.171.35.61www.medewerker.uva.nl /145.18 .10.8 9www.novi.nl /213.154.247.190www.radboudnet.nl /131.174.78 .61

Org

an

i-s

at i

on

id

en

t ifi

er

ww

w

sit

e

La

bs

ra

t in

ga

v.

rat i

ng

CA

tru

st e

d

pro

t oc

ol

ke

y

ex

ch

an

ge

cip

he

rs

MIT

M?

CN

on

c

ert

ific

at e

#A

lt n

am

es

ce

rt v

ali

d

un

t il

ce

rt C

A

cert

typ

eTL

S 1

.1TL

S 1

.0

SS

L 3

.0

SS

L 2

.0+

SS

L 2

.0

se

ss

ion

re

su

mp

t io

ns

t ric

t t r

ans

po

rtin

sec

ure

re

ne

g.

PC

I

FIP

S r

ea

dy

#c

yp

her

sc

yp

he

r ra

ng

e

#w

ea

k

cy

ph

s#

ins

ec

c

yp

hs

F 75% U 55% 8 0% 90% N - 2 14-05-11 DV 2 Y Y Y Y Y N Y N N 9 128 -256 0

C 61% T 8 5% 40% 60% N 1 06-10-12 ? 2 Y Y Y N Y N N N N 18 40-256 10

F 51% U 55% 40% 60% Y - 1 28 -06-11 DV 2 Y Y Y Y ypos4.ypos.nl N N Y N N 25 40-256 14

- - - - - - N 2 20-09-13 ? 2 - - - - - - - - - - - - -

F 51% U 55% 40% 60% Y - 1 22-08 -13 ? N Y Y Y Y Y N Y N N 20 40-256 12

D 48 % T 55% 40% 50% N 1 06-01-12 ? 2 Y Y Y Y - N N N N N 13 40-168 8

F 51% U 55% 40% 60% N - 1 26-12-08 UTN ? 1 Y Y Y Y Y N Y N N 25 40-256 14

F 8 8 % U 8 5% 90% 90% N - 2 06-04-13 UTN ? 2 Y Y Y N - Y N Y N N 8 128 -256 0

F 51% U 55% 40% 60% Y - 1 08 -02-11 ? 1 20 40-256

F 48 % U 55% 40% 50% N - 1 04-09-11 ? 2 Y Y Y Y vs390.uniserver.nl Y N N N N 14 40-168 8

TOTALS 40 34 59% 59% 63% 4 9% 64 % 1 8 % 1 5 2 DV+EV 30% 1 00% 1 00% 1 00% 7 3% 8 8 % 0% 58 % 9% 0% 31 73%

EV 3%

i ctz www.ictz .nl /8 3.161.230.28 PositiveSSLa8 3-161-230-28 .adsl.xs4all.nl

i nf oepd www.infoepd.nl /92.42.239.177 www.infoepd.nl Getronics www.infoepd.nl

kcwz www.kcwz.nl /8 7.253.140.24 Thawte

l i teratuur.amcliteratuur.amc.nl /145.117.204.116 literatuur.amc.nl Terena

psy chiatr ienetwww.psychiatrienet.nl /217.18 .75.176 Clickhere hosted.by.qweb.nl

sbv -z www.sbv-z .nl /217.140.1.245 www.sbv-z .nl Getronics

transmuraalwww.transmuraal.com /8 2.150.141.120 zadkine.protagonist.nl

y sl www.ysl.nl /62.58 .77.5

zichtbarezorg www.z ichtbarezorg.nl /194.9.8 4.159 Equifax shared.dmdelivery.com

zorgdraadwww.zorgdraad.nl /8 3.143.18 6.226 Verisign

Org

an

i-s

atio

n

ide

nt i

fier

ww

w s

ite

Lab

s r

at i

ng

av.

rat i

ng

CA

tru

st e

dp

rot o

co

l

key

ex

ch

ang

eci

ph

ers

MIT

M?

CN

on

cert

ific

ate

#A

lt n

am

es

cert

va

lid

un

t il

cert

CA

cert

typ

ere

vo

ca

t io

n

met

ho

dTL

S 1

.0

SS

L 3

.0

SS

L 2

.0+

SS

L 2

.0

serv

er

ho

st

nam

e

ses

sio

n

res

um

pt i

on

stri

ct

t ran

sp

ort

inse

cu

re

rene

g.

PC

I

FIP

S r

ea

dy

#cy

ph

ers

cyp

he

r ra

nge

#we

ak

cyp

hs

Appendix I: spreadsheet internet security

Teus Hagen – SSL/TLS sec. in Holland NLUUG security & privacy conf. Nov 2010 V1.4 44/44

A 93% T 90% 100% 90% N 17 30-05-12 EV 2 N Y N N N Y N Y Y N 8 128 -256 0 0

F 8 8 % U 8 5% 90% 90% Y 6 13-05-12 CAcert ? 1 ? Y Y Y N N N Y N N 8 128 -256 0 0

A 8 1% T 8 5% 8 0% 8 0% N 1 03-03-12 ? 2 N Y Y Y N Y N N Y N 2 128 -168 0 0

C 52% T 55% 40% 60% Y 1 02-03-12 ? 2 N Y Y Y Y Y N Y N N 20 40-256 9 0

A 8 7% T 90% 8 0% 90% Y 1 24-05-11 ? 2 N Y N N N Y N Y Y N 8 128 -256 0 0

A 8 1% T 8 5% 8 0% 8 0% Y 2 17-04-12 ? 2 N Y Y Y N N N Y Y N 4 128 -168 0 0

F 58 % T 8 5% 0% 90% Y 1 14-12-10 ? 2 N Y Y Y N Y N Y Y N 9 128 -256 0 3

A 91% T 8 5% 100% 90% Y 1 23-11-12 EV 2 N Y Y Y N Y N Y Y N 8 128 -256 0 0

A 8 8 % T 8 5% 90% 90% N 1 25-08 -12 EV 2 N Y Y Y N N N N Y N 6 128 -256 0 0

F 51% U 55% 40% 60% Y - 1 01-05-37 local ? N N Y Y Y Y Y N Y N N 24 40-256 9 0

- - - - - - N - - - - - - - - - - - - - - - - - - - -

A 8 4% T 8 5% 90% 8 0% N 1 03-06-11 EV 2 N Y Y Y N Y N Y Y N 1 168 -168 0 0

ripe A 8 5% T 8 5% 8 0% 90% N 2 17-04-12 ? 2 N Y Y Y N Y N Y Y N 8 128 -256 0 0

F 91% U 8 5% 100% 90% N 4 07-10-12 CAcert ? 1 ? Y Y Y N Y N Y N N 10 128 -256 0 0

A 8 8 % T 8 5% 90% 90% N 1 10-02-11 EV 2 N Y Y Y N Y N Y Y N 14 128 -256 0 0

A 8 8 % T 8 5% 90% 90% Y 2 15-07-11 EV 2 N Y Y Y N Y N Y Y N 8 128 -256 0 0

C 52% T 55% 40% 60% Y 1 29-11-10 ? 2 N Y Y Y Y N N Y N N 20 40-256 12 0

T OT ALS 1 7 1 6 7 9% 81 % 80% 7 4 % 83% 53% 1 0 DV+EV 35% 0% 100% 88% 88% 1 9% 7 5% 0% 88% 69% 0% 4 1 9% 6%

EV 35%

cert.startcomcert.startcom.org /192.116.242.6 www.startcom.org StartCom

cacertcacert.org /213.154.225.245 www.cacert.org

evsslwww.evssl.nl /62.58 .44.113 www.evssl.nl DigiN otar

pinkroccadecspwww.pinkroccadecsp.nl /8 0.79.97.226 www.pinkroccadecsp.nl Verisign

drs.domain-registrydrs.domain-registry.nl /94.198 .154.136 drs.domain-registry.nl Verisign

lirportal.ripe lirportal.ripe.net /193.0.0.206 *.ripe.net DigiCert

sidnwww.sidn.nl /213.136.31.216 *.sidn.nl Thawte

nl.globalsignnl.globalsign.com /213.249.64.244 nl.globalsign.com GlobalSign

openproviderwww.openprovider.nl /8 9.255.0.53 www.openprovider.nl Verisign

perfectviewoverheidwww.perfectviewoverheid.nl /212.61.33.8

quovadisglobalwww.quovadisglobal.nl /6.53.176.66

quovadisglobal www.quovadisglobal.nl /6.53.176.70 www.quovadisglobal.nl QuoVadis

www.ripe.net /193.0.6.139 *.ripe.net DigiCert

nlnetlabswww.nlnetlabs.nl /213.154.224.1 www.nlnetlabs.nl

sslcertif icatenwww.sslcertif icaten.nl /94.228 .131.8 1 www.sslcertif icaten.nl Verisign

sslwww.ssl.nu /213.249.64.250 www.ssl.nu GlobalSign

tunix www.tunix.nl /213.136.3.18 www.tunix.nl Verisign

Org

an

i-s

at i

on

id

en

t ifi

er

ww

w

sit

e

La

bs

ra

t in

ga

v.

rat i

ng

CA

tru

st e

d

pro

toc

ol

ke

y

ex

ch

an

ge

cip

he

rs

MIT

M?

CN

on

c

ert

ific

at e

#A

lt n

am

es

ce

rt v

ali

d

un

t il

ce

rt C

A

cert

typ

ere

vo

ca

t io

n

me

tho

dre

vo

ca

t ed

?T

LS

1.0

SS

L 3

.0

SS

L 2

.0+

SS

L 2

.0

se

ss

ion

re

su

mp

t io

ns

t ric

t t r

an

sp

ort

ins

ec

ure

re

ne

g.

PC

I

FIP

S r

ea

dy

#c

yp

he

rsc

yp

he

r ra

ng

e

#w

ea

k

cy

ph

s

#in

se

c

cy

ph

s