On 24 Mar 2023, at 06:18, Sadeep Madurange wrote:

On 2023-03-24 00:53:45, Polarian wrote:

...

I have now realised that this plays more of an issue, I am constantly getting errors such as:

SSL_ERROR_ACCESS_DENIED_ALERT on firefox, and

ERR_SSL_PROTOCOL_ERROR on chromium.

This happens to multiple sites, but only to some, there seems to be no link between them.

For example: https://web.archive.org/web/20130824024508/http://www.baycom.org/~tom/ham/so...

I'm not an expert on these things, but I since I had an SSL issue with the dotnet tools recently, I'll share a few resources I used to troubleshoot mine.

There's a few resources on Arch Wiki that helps you troubleshoot SSL issues:

https://wiki.archlinux.org/title/Transport_Layer_Security https://wiki.archlinux.org/title/OpenSSL https://wiki.archlinux.org/title/Network_Security_Services

I used these to check trusted CAs, manually adding the certificates etc. Guessing things like your system time is correct? I'd try accessing them using some other tool like curl, or text-based browsers. If the issues occurs only with browsers, then try clearing browser cache?

If the issue is only with some sites, perhaps you don't trust the CA for these sites? In the example you provided, the issuer is GoDaddy.

-- Regards, Sadeep PGP: 103BF9E3E750BF7E

Are you maybe hitting this: https://gitlab.com/qemu-project/qemu/-/issues/1471 ? I have'nt read the whole conversation but symptoms sounded like it. //Torxed

On Friday, 24 March 2023 at 00:53 (+0000), Polarian wrote:

I did not notice this issue at first, but reflecting back on it now there seems to be a serious issue with my SSL on my laptop.

Whenever I've had the same problem, the culprit was an incorrect system clock. With the prevalence of OCSP stapling, this causes many hard TLS failures. Hope this is helpful, Jaron

Hello, Unfortunately my system click is syncronised, so this can't be the issue. Thanks, -- Polarian GPG signature: 0770E5312238C760 Website: https://polarian.dev JID/XMPP: polarian@polarian.dev

Nope, it is not the issue, connecting to https://www.google.com/ is fine, and I am connected over TLS 1.3 (I checked the certificate). So I am not sure what is causing this issue. Thanks, -- Polarian GPG signature: 0770E5312238C760 Website: https://polarian.dev JID/XMPP: polarian@polarian.dev

Hi Polarian,

$ curl -v https://web.archive.org/web/20130824024508/http://www.baycom.org/~tom/ham/so...

What's the output of openssl s_client web.archive.org:443

Hello,

Seems to work here on Arch (with testing repos). Check your packages are up-to-date Might be something in your network (man-in-the-middle attack?) # pacman -Q curl openssl glibc curl 8.0.1-1 openssl 3.0.8-1 glibc 2.37-2 # curl --version curl 8.0.1 (x86_64-pc-linux-gnu) libcurl/8.0.1 OpenSSL/3.0.8 zlib/1.2.13 brotli/1.0.9 zstd/1.5.4 libidn2/2.3.4 libpsl/0.21.2 (+libidn2/2.3.4) libssh2/1.10 .0 nghttp2/1.52.0 Release-Date: [unreleased] Protocols: dict file ftp ftps gopher gophers http https imap imaps mqtt pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp Features: alt-svc AsynchDNS brotli GSS-API HSTS HTTP2 HTTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM NTLM_WB PSL SPNEGO SSL threadsafe TLS-SRP UnixSock ets zstd # curl -v https://web.archive.org * Trying 207.241.237.3:443... * Connected to web.archive.org (207.241.237.3) port 443 (#0) * ALPN: offers h2,http/1.1 * TLSv1.3 (OUT), TLS handshake, Client hello (1): * CAfile: /etc/ssl/certs/ca-certificates.crt * CApath: none * TLSv1.3 (IN), TLS handshake, Server hello (2): * TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8): * TLSv1.3 (IN), TLS handshake, Certificate (11): * TLSv1.3 (IN), TLS handshake, CERT verify (15): * TLSv1.3 (IN), TLS handshake, Finished (20): * TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1): * TLSv1.3 (OUT), TLS handshake, Finished (20): * SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 * ALPN: server accepted h2 * Server certificate: * subject: CN=*.archive.org * start date: Jan 19 18:59:49 2023 GMT * expire date: Feb 20 18:59:49 2024 GMT * subjectAltName: host "web.archive.org" matched cert's "*.archive.org" * issuer: C=US; ST=Arizona; L=Scottsdale; O=GoDaddy.com, Inc.; OU=http://certs.godaddy.com/repository/; CN=Go Daddy Secure Certificate Authority - G2 * SSL certificate verify ok. * using HTTP/2 * h2h3 [:method: GET] * h2h3 [:path: /] * h2h3 [:scheme: https] * h2h3 [:authority: web.archive.org] * h2h3 [user-agent: curl/8.0.1] * h2h3 [accept: */*] * Using Stream ID: 1 (easy handle 0x56276070aea0)

GET / HTTP/2 Host: web.archive.org user-agent: curl/8.0.1 accept: */*

* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): * old SSL session ID is stale, removing < HTTP/2 200 < server: nginx/1.19.5 < date: Fri, 24 Mar 2023 12:12:27 GMT < content-type: text/html; charset=utf-8 < x-app-server: wwwb-app220 < x-ts: 200 < x-tr: 2 < x-location: Slash < x-rl: 0 < x-na: 0 < x-page-cache: MISS < x-nid: - < referrer-policy: no-referrer-when-downgrade < permissions-policy: interest-cohort=() -- damjan

Hello, I can confirm this is the issue, on smarty (Three backhaul), the TLS connection fails, when I am on Lebara (Vodafone backhaul) I can access the website. I believe this is in fact MITM, but due to governmental restrictions. Archive.org is considered as illegal, due to the redistribution of copyrighted archived data, there is a good chance this failure is intentional to prevent AND OR log, who is trying to access archive.org I noticed, this issue only arrises within torrent trackers (legal ones btw) and other shady sites. This is scary, because it is not a simple ip block, but a TLS failure? what are they doing? As a note I am using a local recursive DNS server, I am not sure if they DNS block these domains too. Anyone got any ideas or recommendations to do with a shady cellular provider? Thanks, -- Polarian GPG signature: 0770E5312238C760 Website: https://polarian.dev JID/XMPP: polarian@polarian.dev