In the provided CSV's by DigiCert there are 83_267 unique serials and 166_397 crt.sh links (137 have #N/A in the precert column***).
Please note that crt.sh is Precertificates heavy for DigiCert (see https://crt.sh/cert-populations?group=RootOwner).
I did a lookup of all serials and based on 84 batch requests to crt.sh between 2024-07-31T20:06:00Z and 2024-07-31T21:06:00Z this was the result:
These are the match numbers based on the serial and sha256 fingerprint combination. Only 13.69% of the Leaf certificates are found, while 97.31% of Precertificates are found. Because of these numbers, it's not strange that the 137 certificates without Precertificates cannot be found.
At Internet.nl we're seeing IPv6 connection issues on TCP port 25 (SMTP) to mx[1-4].smtp.goog. Either 100% DROP (so no TCP connection) or ⅔ failure to setup connection. At least from AS20857, AS20860 and AS41887.
Can somebody ping Google/Gmail, it seems to be on their side.
Verify it yourself with: $ nc 2001:4860:4802:32::97 25
Replace 32 with 34, 36 or 38 for MX 2, 3 or 4, optionally use telnet / netcat / socat instead of nc.
Please note in all cases ICMP (ping6 / traceroute6) does work.
Researcher of the leak. I got a question from NOS to test the security of a 6-length short code link (https://www.klm.nl/s/xxxxxx) used in text messages. I've tested two ranges (FAbxxx and KLmxxx), which gave a consistent 1% hit ratio of customer data (57% Air France, 43% KLM), NOS tested a smaller size random set (and got about 0.5%), 62^6*0.01=568 million. It was probably base64url (we now know - was also used, not yet got a _ confirmation).
Researcher of the leak. I got a question from NOS to test the security of a 6-length short code link (https://www.klm.nl/s/xxxxxx) used in text messages. I've tested two ranges (FAbxxx and KLmxxx), which gave a consistent 1% hit ratio of customer data (57% Air France, 43% KLM), NOS tested a smaller size random set (and got about 0.5%), 62^6*0.01=568 million. It was probably base64url (we now know - was also used, not yet got a _ confirmation).
It sounds 'late' to make it a docker container, but actually getting the IPv6 testing working with docker was challenging, only recently some IPv6 issues got solved, and the project needs the experimental and ip6tables docker flags to run.
The news.ycombinator.com setup isn't really modern:
- no IPv6 address for the webserver
- no DNSSEC
- no RPKI ROA for webserver BGP routes
- use of TLS 1.0 and no TLS 1.3
- use of insecure* ciphers
- CSP with 'unsafe-inline' in script-src
When I see TLS 1.0 and no TLS 1.3, I assume there is a bit of legacy openssl or at least the configuration of it. Probably wise to update the config since modern browsers don't support TLS 1.0.
Github.com receives a slightly better score [1]. I'm surprised we still consider DNSSEC to be a measurable factor in a sites security ranking. How long until that test is removed? We don't test for HPKP Public Key Pinning any more as adoption halted and many people removed it due to complexity traps that could cause outages. DNSSEC has been experiencing the same problems [2] making businesses hesitant to use it [3]. Ycombinator still gets an "A" for security headers [4]. At times HN gets pointed to AWS's CDN so that is perhaps a way to address the IPv6 short term until IPv6 addresses were added to HN's servers.
I can envision fintech eventually being regulated into adopting DNSSEC. For everyone else it would probably require better tooling and fail-safes.
I just opened https://wizzair.com/ with a default uMatrix config (only loading first party *.wizzair.com resources) and it complains straight away:
Are you human?
An unusual activity was detected from your web browsing activity, which may also be done by a robot or “bot”. For this reason it needs to be verified that you are human. Bots are not allowed to use our website/mobile app in order to protect your privacy and provide a reliable user experience.
Some activities may look like they are done by a bot, such as running multiple sessions of the WIZZ website, or performing more than one search in a web browser.
What if I am not a bot? Read on for a solution.
We take many factors into consideration to make sure real website/mobile app users are properly distinguished from bots. We recommend the following:
• Use the latest version of the supported web browsers (Chrome, Firefox);
• Don’t use your browser in incognito or compatibility mode;
• Don’t use ad blockers as they may conflict with our website’s protection;
• Don’t use anonymizer proxies with botnets to hide your identity;
• Try to book from another device and/or internet connection;
• Use our mobile apps on iOS or Android
Why can bots be harmful?
• Some third parties such as online travel agencies use bots. If you book your WIZZ ticket through their websites, we may not be able to contact you about possible flight disruptions or any relevant changes, and they may also apply additional fees on the top of the ticket price;
• Bots can overload our servers, slowing them down for our real customers.
If you are using a bot, please note that:
• By using automation tools on our website or mobile application, you are violating their terms of use.
• As per these terms, we have the right to detect and block your activity and cancel any booking you make via these channels.
• To provide the best service to our customers, bots can still access the Flight-Search capabilities, but we reserve the right to discontinue or block bot users even from Flight-Search, especially if over-use is detected;
• If you would like to show our flights in your inventory, please contact us beforehand and make sure users are redirected to wizzair.com when they are ready to make their booking. You can also use a deep link to the selected flight.
I did a lookup of all serials and based on 84 batch requests to crt.sh between 2024-07-31T20:06:00Z and 2024-07-31T21:06:00Z this was the result:
These are the match numbers based on the serial and sha256 fingerprint combination. Only 13.69% of the Leaf certificates are found, while 97.31% of Precertificates are found. Because of these numbers, it's not strange that the 137 certificates without Precertificates cannot be found.All 92_423 can be found in this bzip2 compressed attachment in tab-separated values format: https://bugzilla.mozilla.org/show_bug.cgi?id=1910322#c16
These are certificates for 172_047 unique domains, of which 20_702 are wildcard and 71 IP Addresses (63 IPv4 and 8 IPv6).*