In this paper we carry out a systematic analysis of the state of the HTTPS deployment of the most popular Italian university websites. Our analysis focuses on three di erent key aspects: HTTPS adoption and activation, HTTPS certi cates, and cryptographic TLS implementations. Our investigation shows that the current state of the HTTPS deployment is unsatisfactory, yet it is possible to signi cantly improve the level of security by working exclusively at the web application layer. We hope this observation will encourage site operators to take actions to improve the current state of protection.
In our security assessment we use numeric scores to measure the compliance with respect to security best practices, where higher scores stand for better security. At the end of our study, we assign a nal numeric score to all sites and show that the current state of the HTTPS deployment is unsatisfactory, yet it is possible to signi cantly improve the level of security by working exclusively at the web application layer (Section 6). We hope this observation will encourage site operators to take actions to improve the current state of protection. 2 2.1
HTTPS is an encrypted variant of HTTP based on the TLS cryptographic protocol. At a high level, TLS can be described as follows: 1. The client initiates a handshake with the server by proposing a TLS version and a list of supported ciphersuites; 2. The server chooses the lower between its highest supported TLS version and the TLS version proposed by the client. It then picks a supported ciphersuite from the proposed list and sends to the client an X.509 certi cate, which contains information about the server's identity, the server's public key and the issuing certi cation authority; 3. The client con rms the validity of the X.509 certi cate by checking that it was issued by a trusted certi cation authority to the hostname to which it is trying to connect, thus getting a proof of authenticity; 4. The client and the server take appropriate actions to generate a fresh session key, which is used to protect the communication by means of symmetric encryption, thus ensuring its con dentiality and integrity.
The session key establishment can be implemented in di erent ways and takes advantage of the server's public key. 2.2
On the Web, servers are typically identi ed by a fully quali ed domain name (FQDN), i.e., a dot-separated sequence of labels terminated by a top-level domain (TLD) from a xed list. For example, www.unive.it is a FQDN under the TLD .it. Domain registration typically operates at the granularity of TLD+1: this means that an organization can register a domain name like unive.it and then create arbitrary sub-domains like www.unive.it and idp.unive.it. It is common practice to create di erent sub-domains for di erent services, e.g., www.unive.it to serve the university website and idp.unive.it for authentication.
The security of sub-domains plays an important role on web application security, most
notably because sub-domains can share cookies. For example, www.unive.it and idp.unive.it
can both set cookies with the Domain attribute set to .unive.it: such cookies, called domain
cookies, are sent to both services. Though this practice is useful and popular, e.g., to implement
authentication across di erent sub-domains, it also means that attacking www.unive.it might
break the con dentiality and integrity of cookies at idp.unive.it and vice-versa [
We assume an active network attacker who is able to add, remove or modify messages sent between a client and a server. The attacker also controls a malicious website, which is navigated by the attacked client. By means of the website, the attacker can inject scripts in the client from an attacker-controlled origin, which is relevant for a subset of the considered attacks. However, the attacker can neither break the Same Origin Policy (SOP), nor exploit any bug in the browser. We assume the attacker cannot exploit timing side-channels, since the feasibility of such attacks is generally hard to assess.
In our security analysis, we also occasionally make considerations about passive network attackers, who just sni the network tra c and do not take actions to avoid detection. These attackers are particularly interesting because they only require very limited skill. 2.4
We focus on the HTTPS deployment of the Italian universities which are included in the QS
World University Ranking 2020.1 We identi ed 34 universities overall, then extracted their
o cial names from QS and searched for them on Google: the rst website in the results page
is the one we used as the entry point of our security analysis. The rationale of this choice is
that we want to analyse the website which is most likely accessed when users look for a speci c
university via a search engine. We provide the full list of the analysed websites online [
When users access a website like www.unive.it without specifying any protocol, browsers
normally contact the site using the HTTP protocol. A common practice is then to upgrade the
communication to HTTPS through a redirection, e.g., by using the Location header, to send
the browser to https://www.unive.it. Though this practice de nitely improves security over
the plain adoption of HTTP, it is still vulnerable to attacks like SSL stripping [
There are several deployment options for HSTS. Speci cally, HSTS can be activated using
the Strict-Transport-Security header, using the max-age attribute to specify the lifetime
of protection. The includeSubDomains option can be used to extend the HTTPS upgrade to
all the sub-domains of the protected website, which is particularly useful to protect other web
applications and ensure the con dentiality and integrity of cookies shared among them [
Finally, once a website is accessed over HTTPS, it is important that it does not include subresources over HTTP, otherwise the con dentiality and integrity guarantees of HTTPS can be undermined. Modern browsers mitigate this severe threat by implementing the Mixed Content 1https://www.topuniversities.com/university-rankings/world-university-rankings/2020 policy.2 Roughly, this policy mandates that active contents like scripts must be blocked when they are included in HTTPS pages over HTTP connections, while browser vendors are left at liberty of being more tolerant towards passive content like images. It is a good practice to avoid the use of mixed content in high-security sites to ensure appropriate protection also to users of browsers which do not implement the Mixed Content policy, e.g., legacy browsers. It is worth noticing that, starting from 2020, Google Chrome will automatically block all forms of mixed content.3 It is thus even more important to avoid the use of mixed content to prevent breakage. 3.2
To analyse the practices used to activate HTTPS, we have to check for the presence of redirects. Since redirects can be performed using JavaScript, we cannot just check for the use of Location headers and we rather use Puppeteer4 to access the websites over HTTP using Chrome. We then check the protocol used in the nal landing page to see whether HTTPS was activated in some way since the original HTTP request. Since Puppeteer has access to the response headers of the landing page, we can also use it to log the presence of HSTS headers. However, this is not entirely su cient, because HSTS activation can (and should) be forced on the TLD+1 using the includeSubDomains option; we then also check for the presence of such headers there using the curl command line tool. Finally, we assign each website a score as follows: 0 points: no redirection to HTTPS took place. This means that the navigation is performed over HTTP by default, which makes network attacks trivial to carry out; 3 points: redirection from HTTP to HTTPS, but lack of HSTS adoption. The website is vulnerable to SSL stripping, yet it is normally served over HTTPS and careful users might notice when the site is unexpectedly served over HTTP; 5 points: redirection from HTTP to HTTPS + HSTS. The website is protected against SSL stripping, but other applications served on sub-domains might be vulnerable to this attack and domain cookies might be leaked or set over HTTP; 7 points: redirection from HTTP to HTTPS + HSTS with the includeSubDomains option on TLD+1. This ensures that all the applications on the domain are always accessed over HTTPS, as well as granting the con dentiality and integrity of domain cookies.
As for mixed content checking, we still rely on Puppeteer to track all the outgoing HTTP requests of the accessed web pages, including their type. We then assign the following scores: 0 points: presence of active mixed content in the homepage. The integrity of the page is seriously at harm on legacy clients not implementing the Mixed Content speci cation; 1 point: presence of passive mixed content in the homepage. Website defacement is potentially possible and there is a signi cant risk of privacy breaches due to the presence of outgoing HTTP requests, even on modern clients which are tolerant on such content; 2 points: there is no presence of mixed content in the homepage. This ensures that the full page content is served over encrypted connections, which is necessary to provide optimal con dentiality and integrity guarantees. 2https://www.w3.org/TR/mixed-content/ 3https://blog.chromium.org/2019/10/no-more-mixed-messages-about-https.html 4https://github.com/puppeteer/puppeteer
Based on this scoring system, websites with a score lower than 5 are not secure even against passive network attackers, since they either do not redirect to HTTPS or include some HTTP content in the homepage. A minimal score for protection against active network attackers is 7: this ensures that SSL stripping is not possible and that the con dentiality and integrity of the homepage cannot be trivially harmed by the use of mixed content. 3.3
The rst observation we make is that the majority of the websites is eventually accessed over HTTPS: this is the case for 28 out of 34 websites (82%). As to the remaining 6 websites, we observed that web.uniroma2.it, poliba.it, www.unina.it and www.unipa.it do not perform any redirection to HTTPS, but can still be accessed over HTTPS when the protocol is explicitly typed in the browser address bar. This means that users can access these sites securely, but the very large majority of users is normally left unprotected; in particular, even passive network attackers have full visibility of the exchanged HTTP tra c. The other two websites are even more problematic from a security perspective, because www.uniroma3.it cannot be accessed over HTTPS and www.unife.it forces an explicit downgrade from HTTPS to HTTP using JavaScript. We manually veri ed that both websites have a private area, which is accessible over HTTPS. However, this is clearly not su cient for security, because an active network attacker can break the integrity of the homepage and force the adoption of the HTTP protocol also on the private area. Given that it is not possible to navigate these two sites over HTTPS, we excluded them from all further analyses.
As to the 28 websites which force the activation of HTTPS in some way, they mostly do it by means of redirects: we observed that this is the case for 25 websites. The security implication is that the majority of the Italian university websites are vulnerable to SSL stripping. Only 3 websites make use of HSTS: www.unibo.it, www.unifi.it and www.polimi.it, with the latter two even activating the includeSubDomains option. Unfortunately, in both cases, this is not done on the TLD+1, but on the www sub-domain, which essentially voids protection.
As for the presence of mixed content, the picture is largely positive, yet we also observed two insecure practices due to the use of passive mixed content. First, www.unina.it includes an image over HTTP, which is su cient to leak the website cookies even against a passive network attacker who just sni s the HTTP tra c. A second problem a ects www.unipa.it, where the form of the internal search engine is sent over HTTP: this might not only expose the website cookies, but also reveal all the search keywords typed by the website users, including the corresponding results.
The complete picture of this part of our analysis is summarized by the scores in the
\Activation" column at [
It is well-known that certi cates should only be signed by a trusted certi cation authority and should only be considered valid up to a given expiration date. What is likely less known is that certi cates come in di erent forms. In particular, by increasing level of security guarantees: 1. Domain Validated (DV) certi cates are issued after proving some form of control over a given domain name, but do not provide any form of binding between the domain name and the organization which claims ownership of the domain; 2. Organization Validated (OV) certi cates are only issued after proving that a domain name is actually controlled by a given physical organization. This requires the presentation of appropriate documentation about the organization asking for the certi cate; 3. Extended Validated (EV) certi cates are similar to OV certi cates, but are subject to even stricter security checks. Browsers often rely on custom security indicators for EV certi cates and show the name of the owning organization directly in the address bar.
Major organizations like universities should only use OV or EV certi cates, since DV certi cates provide no protection against phishing attempts. For example, an attacker could get a valid DV certi cate for www.unvie.it and host a website which pretends to be the legitimate website of Universita Ca' Foscari Venezia (www.unive.it).5
Moreover, security-conscious administrators should avoid the use of wildcard certi cates. Wildcard certi cates apply to arbitrary sub-domains like *.unive.it, hence are typically reused on a multitude of di erent hosts. This simpli es the HTTPS deployment, but also implies that all such hosts have access to the same cryptographic keys, hence the compromise of any host would su ce to get read and write access to all the HTTPS tra c exchanged with any subdomain of unive.it. Wildcards cannot be used in EV certi cates, but it is worth noticing that even certi cates which do not make use of wildcards might be unduly issued for a large number of domains by specifying multiple Subject Alternative Names (SANs) in them. 4.2
We check the use of certi cates at the analysed websites by using the openssl tool from the command line. In particular, we rely on the following scoring system: 0 points: the certi cate is not signed by a trusted certi cation authority or has expired. In the former case a network attacker can just replace the server's certi cate with a fake one while going unnoticed, while in the latter case it is plausible that keys might have been compromised over time, e.g., by brute-forcing; 2 points: the website uses a valid DV certi cate signed by a trusted certi cation authority. This provides both con dentiality and integrity, but not necessarily authenticity; 4 points: the website uses a valid OV certi cate signed by a trusted certi cation authority. This gives attentive and technically educated users a way to check the identity of the server's organization when in doubt; 5We actually registered www.unvie.it after realizing that this is one of our most common typos... 5 points: the website uses a valid EV certi cate signed by a trusted certi cation authority. This provides immediate visual feedback about the identity of the server's organization or at least easy access to this information.
Finally, we award 2 extra points to certi cates which are only valid for a \small" number of domain names. Such certi cates do not make use of wildcards and keep the number of SANs under a given threshold t. To choose t, we rely on the distribution of the number of SANs in the collected certi cates as reported below.
Based on this scoring system, certi cates should be awarded at least 6 points to be considered compliant with security best practices: this requirement is satis ed by OV and EV certi cates with only limited reuse on multiple domains. 4.3
We start by discussing a positive result: all the analysed websites have valid certi cates and none of them relies on DV certi cates. This means that minimal security practices to ensure communication security and complicate phishing attempts are put in place, and all websites were awarded at least 4 points. Only 5 websites, however, use EV certi cates: www.unimore.it, www.unipg.it, www.unitn.it, www.uniud.it and www.unive.it. An interesting fact is that all the collected certi cates were issued by the same certi cation authority (TERENA).
We also noticed that only two websites make use of wildcard certi cates, i.e., www.unibo.it and www.unicatt.it. This means that most certi cates cannot be arbitrarily reused on subdomains, which is important to minimize the risk of leaking private keys and reduce the attack surface. There are however a few interesting observations about the use of SANs, since their distribution is highly skewed. In particular, the mode of the distribution is 2, the mean is 21.7 and the variance is 47.4. We show the full frequency table of the number of SANs in Table 1. Observe that there are a few cases where the certi cate is valid for so many domains that it is essentially equivalent to having a wildcard: for example, the certi cate of www.unifi.it is valid on 247 di erent domains. Based on the collected numbers, we empirically set the threshold t = 10: indeed, 24 out of 32 certi cates use a number of SANs which is lower than this threshold, hence it is common practice to avoid a more widespread certi cate reuse.
The complete picture of this part of our analysis is summarized by the scores in the \Certi
cate" column at [
Even when HTTPS is up and running, cryptographic aws in the implementation of TLS may
break its intended security guarantees. Researchers identi ed several attacks against TLS in
the past, which may even lead to the disclosure of the cryptographic keys used to protect the
HTTP tra c [
Given a domain name like www.unive.it, the tool performs a cryptographic assessment of all the hosts to which www.unive.it might resolve. Moreover, the tool also analyzes all the hosts to which any other sub-domain of unive.it might resolve, since other web applications might be hosted there. Finally, the security analysis is done on all the hosts from which the web page at www.unive.it is including content, e.g., scripts and stylesheets. Cryptographic vulnerabilities on such hosts might seriously undermine page integrity and introduce con dentiality breaches, despite the adoption of the HTTPS protocol.
The output of the tool builds on the following taxonomy of insecure channels: 1. Leaky channels: established with servers vulnerable to con dentiality attacks, which give the attacker the ability to decrypt the network tra c; 2. Tainted channels : susceptible to man-in-the-middle attacks, which give the attacker the ability to decrypt and arbitrarily modify the network tra c. Observe that tainted channels are also leaky by de nition; 3. Partially leaky channels : su ering from side-channels, which give the attacker the ability to disclose selected \small" secrets (like cookies) over time. Observe that leaky and tainted channels also qualify as partially leaky. 5.2
We assign to each website a score from 0 to 4 based on the following system: 1 point: no (partially) leaky channel on the main domain or domains from which resources are loaded from the homepage. This ensures that network attackers cannot leverage cryptographic aws to disclose information on the homepage; 1 point: no tainted channel on the main domain or domains from which resources are loaded from the homepage. This ensures that network attackers cannot exploit cryptographic aws to undermine the integrity of the homepage; 1 point: no (partially) leaky channel on sub-domains. This is important at the very least to ensure the con dentiality of domain cookies; 1 point: no tainted channel on sub-domains. This is important at the very least to ensure the con dentiality and integrity of domain cookies.
Notice that, since tainted channels are also (partially) leaky, integrity violations e ectively weigh twice as much as con dentiality violations in our scoring system. 5.3
At the end of our measurement, we analysed 2,654 domains. In particular, we scanned 2,601
sub-domains of Italian universities and 53 external domains from which resources are loaded on
the homepage of the analysed websites, the large majority of these being well-known analytics
or library providers. This is already an interesting observation, because it shows that the attack
surface is mostly under the control of the universities and does not signi cantly depend upon
the security settings of external entities. This is in stark contrast with what we observed in
general websites from the Alexa list [
A positive result of our analysis is that, as long as we focus on the main domain and the
homepage of the analysed websites, the quality of the cryptographic deployment is very high.
We were not able to nd any cryptographic aw which could a ect the con dentiality and the
integrity guarantees of the homepages. Unfortunately, the picture is way less positive when
we turn our attention to sub-domains, given the size of the attack surface. In particular, we
found tainted channels on at least one sub-domain on 15 out of 32 analyzed main domains. The
key culprits of this are vulnerabilities enabling attacks like DROWN [
We draw the key conclusions of our study, discussing ethical considerations and limitations. 6.1
To understand the state of the HTTPS deployment on the Italian university websites, we take
a nal look at the collected data [
In the end, our analysis shows that the current state of the HTTPS deployment of Italian university websites is unsatisfactory, because active network attackers have easy life on the very large majority of the analysed sites. However, our analysis also has positive implications, because it shows a reasonable state of health of the certi cate and cryptographic ecosystems. This means that many websites can improve their security with limited e ort by exclusively working at the web application layer. In particular, we observe that activating HSTS on the 25 websites marked as at risk would lead to the following improvement: 16 websites would be deemed acceptable and 9 websites would be considered close to secure (or even better). We hope this observation will encourage site operators to take actions to improve the current state of protection. 6.2
Due to both legal and ethical reasons, our analysis of TLS vulnerabilities in the wild was limited
to an unintrusive scan based on the use of publicly available tools. The exploitability of the
discovered vulnerabilities was exclusively judged through a systematic analysis of the output of
those tools, as discussed in previous work [
A limitation of our analysis is that it considers the homepage of the website as the key entry point. Though this makes sense from the perspective of a navigation session, it is possible that security-sensitive services are deployed on external domains which we did not analyse. Notice, however, that we provided a reasonable coverage of the security guarantees of sub-domains. A second limitation of our study is that we did not authenticate to the analysed websites, because we do not own valid access credentials for them. Finally, it is worth mentioning that our analysis is entirely focused on network attackers: we leave the study of security mechanisms designed to prevent web attacks to future work.
We are making plans to responsibly disclose all our results with the technical sta of the universities involved in our study. For now, we contacted our own IT o ce at Ca' Foscari and convinced them to activate HSTS on www.unive.it. We hope we will be just as successful with further disclosures. 7
Many papers presented attacks exploiting cryptographic vulnerabilities in TLS, like DROWN [
Besides cryptographic vulnerabilities, there might be several other reasons why HTTPS
deployments turn out to be susceptible to attacks [
The present paper positions itself in the popular research line of security measurements of
the Web. For example, previous work analyzed the security of European sites [