Unsolved Always Use Secure Connection (HTTPS)

greatkingrat

I have "Always Use Secure Connection (HTTPS)" enabled. However, when I type a domain (no http: or https: or other URL scheme) name in the address bar, I'm taken first to a domain's http: address and then get a redirect to the https web site.

How do I make Vivaldi use https: first?

yngve

@greatkingrat The actual HTTPS policy is now something called "HTTPS First", in which, even if the scheme is HTTP (which is the default when not adding a scheme), the HTTPS port (443) is tested, and if it responds with a valid response, it is used, without ever connecting to the HTTP port (80), and the URL is locally redirected (without any input from the server, there is a special indication in developer tools network logs for such actions). "Always use HTTPS" is actually not that much used as a codepath anymore (HTTPS First comes first (pun not intended) in the sequence), due to that new policy (and I anticipate that it might be removed eventually).

Additionally, if the server is registered with a HSTS flag (which can be configured by the server, or via a pre-shipped list), HTTPS will always be used.

greatkingrat

That doesn't seem to be the case. I have all the flags for HTTPS First enabled as well.

2024-08-17 12.03.38 flags dedff848d357.png

This is the log from developer tools when I enter "abebooks.com".

It attempts to load http://abebooks.com/ and gets a 307 redirect.
Then it loads https://abebooks.com/ and gets a 301 redirect.
Then it finally loads https://www.abebooks.com/

Additionally, the http:// address goes into the browser history, and that appears first for auto-complete.

yngve

@greatkingrat I suspect there are quite a few rules involved, possibly including how quickly the 443 port responds, the point being that it will try to avoid delaying the user navigation, so if the 443 port has not responded within X milliseconds it may connect to 80 anyway.

Re your example, I think you will find that the 307 response view have a "HttpsUpgrade" as the reason for the redirect, meaning that it is a locally enforced redirect generated by Chromium (possibly triggered by HSTS being set during the first load), not (at that stage) triggered by the server's response (which was 301).

Also keep in mind that the www server is the real host, not the domain; that only redirects to the www host.

greatkingrat

Ran tcpflow. It's definitely seeing http requests that are going to the server.

010.000.000.162.53622-075.002.069.186.00080: GET / HTTP/1.1
Host: abebooks.com
Connection: keep-alive
DNT: 1
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.0.0 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9


075.002.069.186.00080-010.000.000.162.53622: HTTP/1.1 301 Moved Permanently
Server: awselb/2.0
Date: Sat, 17 Aug 2024 19:36:37 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 237
Connection: keep-alive
Location: https://www.abebooks.com/

<!doctype html>
<html lang=en>
<title>Redirecting...</title>
<h1>Redirecting...</h1>
<p>You should be redirected automatically to the target URL: <a href="https://www.abebooks.com/">https://www.abebooks.com/</a>. If not, click the link.

Pathduck

@yngve That's how it's supposed to work, but this (HTTPS-first/Always Secure) has never worked properly in Vivaldi.

Here's Vivaldi, default settings - i.e. HTTPS First should be in effect:

λ tshark -i4 dst host www.abebooks.com
Capturing on 'Ethernet'
    1   0.000000 192.168.0.10 49597 server-54-240-174-119.osl50.r.cloudfront.net 80 TCP 66 49597 → 80 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 WS=256 SACK_PERM
    2   0.000208 192.168.0.10 49598 server-54-240-174-119.osl50.r.cloudfront.net 80 TCP 66 49598 → 80 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 WS=256 SACK_PERM
    3   0.000730 192.168.0.10 49599 server-54-240-174-119.osl50.r.cloudfront.net 443 TCP 66 49599 → 443 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 WS=256 SACK_PERM
    4   0.001266 192.168.0.10 49597 server-54-240-174-119.osl50.r.cloudfront.net 80 TCP 54 49597 → 80 [ACK] Seq=1 Ack=1 Win=263424 Len=0
    5   0.001644 192.168.0.10 49598 server-54-240-174-119.osl50.r.cloudfront.net 80 TCP 54 49598 → 80 [ACK] Seq=1 Ack=1 Win=263424 Len=0
    6   0.001936 192.168.0.10 49599 server-54-240-174-119.osl50.r.cloudfront.net 443 TCP 54 49599 → 443 [ACK] Seq=1 Ack=1 Win=263424 Len=0
    7   0.002525 192.168.0.10 49599 server-54-240-174-119.osl50.r.cloudfront.net 443 TCP 1494 [TCP segment of a reassembled PDU]
    8   0.002525 192.168.0.10 49599 server-54-240-174-119.osl50.r.cloudfront.net 443 TLSv1 340 Client Hello (SNI=www.abebooks.com)

The initial connection is made to port 80.

Here's basically every other browser, default settings. Example is from Chrome 127:

λ tshark -i4 dst host www.abebooks.com
Capturing on 'Ethernet'
    1   0.000000 192.168.0.10 51070 server-54-240-174-18.osl50.r.cloudfront.net 443 TCP 66 51070 → 443 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 WS=256 SACK_PERM
    2   0.000331 192.168.0.10 51071 server-54-240-174-18.osl50.r.cloudfront.net 443 TCP 66 51071 → 443 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 WS=256 SACK_PERM
    3   0.001545 192.168.0.10 51070 server-54-240-174-18.osl50.r.cloudfront.net 443 TCP 54 51070 → 443 [ACK] Seq=1 Ack=1 Win=263424 Len=0
    4   0.002257 192.168.0.10 51071 server-54-240-174-18.osl50.r.cloudfront.net 443 TCP 54 51071 → 443 [ACK] Seq=1 Ack=1 Win=263424 Len=0
    5   0.003604 192.168.0.10 51070 server-54-240-174-18.osl50.r.cloudfront.net 443 TCP 1494 [TCP segment of a reassembled PDU]
    6   0.003604 192.168.0.10 51070 server-54-240-174-18.osl50.r.cloudfront.net 443 TLSv1 372 Client Hello (SNI=www.abebooks.com)

There are no HSTS policies in place for www.abebooks.com or abebooks.com.

Another thing is that Vivaldi insists on loading the HTTPS port even when the user explicitly specifies HTTP, even with the Always Secure setting disabled, something other browsers do not do, and which causes problems on some sites HTTPS is not correctly configured. There's been several topic about this.

One example of the latter is trying to load http://ascii.textfiles.com/ - This will fail to load the CSS because of CORS in Vivaldi, Chrome etc will load it just fine ("insecure" but working).

yngve

@Pathduck said in Always Use Secure Connection (HTTPS):

Another thing is that Vivaldi insists on loading the HTTPS port even when the user explicitly specifies HTTP, even with the Always Secure setting disabled, something other browsers do not do, and which causes problems on some sites HTTPS is not correctly configured. There's been several topic about this.

And as I have said before: The reason for that is that there is special logic in the Chromium Omnibox (the Chromium address bar) for that; Vivaldi does not use the Omnibox, so that logic is unavailable as the flag is handled in a completely different codepath, one that our UI cannot use.

@Pathduck said in Always Use Secure Connection (HTTPS):

Example is from Chrome 127

You know what I say about testing in Chrome/Chromium: Always use the same version as the Chromium version as Vivaldi is using. For 6.8 that is Chromium 126 (Extended Stable). For newest 6.9 snapshot, that is Chromium 128 Beta (soon to be Stable).

I am sure the Chromium devs are constantly tweaking the HTTPS first code to handle corner cases as they show up in their telemetry data.

What I saw just now, reported by devtools in 6.9 with Chromium 128 (in a profile that had never seen the domain) is that the HTTP (80) connection was stalled for 1.92 ms, then everything was done in the HTTPS (443 connection, including DNS and requests). Looking at the HTTP request and response the contents were decidedly odd, including specifying the scheme in the request as HTTPS. The debug logging to command line did not indicate that a HTTP 80 URL was requested, only the HTTPS URL.

BTW, www.abebooks.com sets a HSTS policy, but not for the domain.

It has been a while since I looked at the https-first/always https logic, so I don't remember what the code looked like, but the way I would have implemented it if I wrote the code, would be that the always HTTPS setting would never be checked used unless https first was completely disabled. (and Always HTTPS are creating a lot of problems for HTTP-only sites, which is why HTTPS first is preferred, and disabled by default in any case.)

Pathduck

@yngve said in Always Use Secure Connection (HTTPS):

And as I have said before: The reason for that is that there is special logic in the Chromium Omnibox (the Chromium address bar) for that; Vivaldi does not use the Omnibox, so that logic is unavailable as the flag is handled in a completely different codepath, one that our UI cannot use.

I think my point is that users except a certain behaviour from browsers, and if Vivaldi does things differently, they will think it's a bug and not behaving as it should. So we will get these topics again and again...

For me, it's no big deal, I don't really care if my browser sends a single packet or two to port 80 before it triggers HTTPS. But others do (apparently).

BTW, www.abebooks.com sets a HSTS policy, but not for the domain.

True, but only by HTTP header, there's no preloaded policy. So the browser has to make a HTTPS connection first to get the policy set. Once the policy is set , subsequent connections are done using HTTPS First so that's correct.

Anyway my main pet peeve is more the Vivaldi forcing HTTPS even when the user explicitly asks for HTTP by specifying the protocol, but that's another matter.

Pathduck

@greatkingrat Really strange that your tcpflow output shows a HTTP connection to the site.

All I'm seeing with tshark are TCP handshake packets to port 80, i.e. SYN/ACK packets.

These will be sent in any case, no matter the port and so do not matter for security/privacy. However if the browser sends an actual HTTP request that's different to just a TCP handshake.