I checked the public websites of financial exchanges, trading platforms, and markets to see how many of them used HTTPS to protect the contents of their website in transit.
Financial exchanges are organisations, such as NASDAQ, Deutsche Boerse, ASX, or Barclays, which are involved with handling a lot of transactions.
This year has seen an increase in the number of exchange websites that do use TLS. As an example, the JPX group in Tokyo, Japan - encompassing TSE, OSE, TOCOM - has added TLS recently, as did the ASX.
In the July releases of most major browsers, any website that is delivered over HTTP is marked as insecure. That is not a good look for a financial exchange.
By "not a good look" I also mean that their regulators might be rapping some finger knuckles.
Actual trading isn't done through the website, typically. The website is responsible for non-trading materials such as exchange regulations, exchange orders, information on trading halts, publishing closing prices (which are used for benchmarks and settlements), resetting user passwords, and other terribly important things.
Also, exchange websites are terrific for watering hole attacks - something that HTTPS makes easier to spot.
I do not have enough space here to argue at length to convince every site must use HTTPS. Others have done so at more length and more eloquently. Instead, check with your regulator about the minimum security requirements you need, then add HTTPS.
There are 820 websites for 1601 exchanges in the 2018-06 ISO 10383 list. This is the master list for exchanges and markets. Note that multiple exchanges can share the same website.
383 have no version of TLS available.
TLSv1.0 = 310 sites. This is the minimum version that a website should have, and there should be plans in place to migrate away from its use.
TLSv1.2 = 369
TLSv1.3 = 12 ... well done on those that are able to get it into production so soon.
Note that these figures do not sum exactly which is because sites can have between 0 and 3 versions of TLS available. Also I was unable to check for SSLv3 because support is disappearing from the recent libraries I used.
For a complete table, check out the table, or a look at a chart.
438 sites didn't successfully complete a TLS connection. This involves certificate errors (untrusted issuers), incorrect hostnames (eg, where a company has been purchased by another, or they have only partially configured their Akamai setup), or simply not having TLS at all.
In this case, the best course of action for the exchange operator is to add TLS in front of your existing website. Or fix your configuration errors.
There are a few fun exchanges which have TLS available on their sites, but in a fit of misconfiguration or foolishness will redirect you back to their plain text equivalents.
This is rather mind blowing. They have the technology, the certificate, but then force clients to not use it.
The main part of the search is done with Python 3 and a custom build of the latest PycURL/7.43.0.2, libcurl/7.60.0, and OpenSSL/1.1.1. I wrote a bit of glue to parse the list of MICs, extract the unique websites, then check each in turn.
Symantec certificate authorities are deprecated and will soon be completely untrusted).
I only checked the supplied intermediates and not the entire chain. Also I didn't check whether they were from the new Symantec CA. Of the 33 that had a Symantec certificate in their chain, the ones that I spot checked had already been reissued and were accepted by the new Chrome browser.
For such important institutions the turn out a week before HTTP websites are marked as untrusted in major browsers is poor.
For sites that are under strict regulation about the quality of the security involved, to have sites that are still insecure HTTP is not great.
Want the full breakdown? Look at the Table.
There are different versions of TLS are available. Generally, any version is better than none. As sites can support any combination of plain HTTP (insecure), TLSv1.0 (weak), TLSv1.2 (best), TLSv1.3 (newest), there is quite a patchwork in the results.