#956712 emacs: https to plain http downgrade after unhandled GNUTLS_E_AGAIN error in TLS1.3 connection

Package:
emacs
Source:
emacs
Submitter:
Heenec
Date:
2024-02-26 13:15:04 UTC
Severity:
grave
Tags:
#956712#5
Date:
2020-04-14 18:17:17 UTC
From:
To:
Dear Maintainer,

When I have tried to install a package from the GNU ELPA repository, I
received a "Bad Request" error. Searching on the Internet for a solution
of this problem led me to this bugreport at debbugs.gnu.org:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=34341

I have confirmed, that the bug reported there can be reproduced in my
emacs installation, and that the workaround mentioned there (disabling
TLS1.3) works.

But while playing around with this bug I noticed, that for some reason
after breaking the TLS1.3 connection it makes second connection with
plain http to the port 443 (sic!).

#### Steps to reproduce:

1) Run emacs
2) Open scratchpad with "C-x b *scratch*"
3) Write the following snippet and execute it by positioning cursor
after the
last ")" and pressing C-j.
```
(switch-to-buffer (url-retrieve-synchronously "https://duckduckgo.com")
                  (buffer-string))
```

#### Results:

A new buffer with following content is opened:
```
HTTP/1.1 400 Bad Request
Server: nginx
Date: Fri, 02 Apr 2020 12:54:12 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 248
Connection: close
X-XSS-Protection: 1;mode=block
X-Content-Type-Options: nosniff
Referrer-Policy: origin
Expect-CT: max-age=0

<html>
<head><title>400 The plain HTTP request was sent to HTTPS
port</title></head>
<body>
<center><h1>400 Bad Request</h1></center>
<center>The plain HTTP request was sent to HTTPS port</center>
<hr><center>nginx</center>
</body>
</html>
#<buffer  *http duckduckgo.com:443*>
```

Also if network traffic was captured with Wireshark, it can be seen,
that breaking of the TLS1.3 connection follows with a plain http request
to port 443 on the same IP address. And the result of this http request
is returned by the url-retrieve-synchronously function.

The same behaviour is seen in network captures of (failing) emacs
package installation process.

Althogh the bug mentioned in
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=34341 seems to be
currently fixed in upstream emacs 26.3 and 27.1, the related patch fixes
wrong handling of GNUTLS_E_AGAIN error, but not this fallback from https
to plain http. It suggests, that this behaviour may be triggered by
other exceptions.

Heenec
#956712#10
Date:
2020-05-17 15:27:17 UTC
From:
To:
fixed 956712 1:26.3+1-2
thanks

I can confirm that as reported by Heenec, this is fixed in unstable
given it's on 26.3 now.
#956712#17
Date:
2020-07-01 08:34:18 UTC
From:
To:
Yes, you are actually right, this bug should not belong to the emacs
metapackage, but to one of its dependencies. It's my mistake.

I suppose, that the actual bug may reside in emacs-common or in
emacs-bin-common, on which emacs-gtk and emacs-lucid depend, but I am
not sure.

And no, the emacs metapackage depends on emacs-gtk, emacs-lucid or
emacs-nox, so your installation is very likely affected.

Thank you for noticing.

Heenec
#956712#26
Date:
2024-02-26 13:10:27 UTC
From:
To:
According to the bug log this was fixed in 2020, but the bug wasn't
closed for reasons that are unclear. Close it now.