Your message dated Mon, 26 Feb 2024 15:10:27 +0200
with message-id <87edczz7zw....@iki.fi>
and subject line Close the bug
has caused the Debian Bug report #956712,
regarding emacs: https to plain http downgrade after unhandled GNUTLS_E_AGAIN
error in TLS1.3 connection
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
956712: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956712
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: emacs
Version: 1:26.1+1-3.2+deb10u1
Severity: grave
Tags: security
Justification: user security hole
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
-- System Information:
Debian Release: 10.3
APT prefers stable
APT policy: (990, 'stable'), (500, 'stable-updates')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.19.0-8-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages emacs depends on:
ii emacs-gtk 1:26.1+1-3.2+deb10u1
emacs recommends no packages.
emacs suggests no packages.
-- no debconf information
--- End Message ---
--- Begin Message ---
Version: 1:26.3+1-2
According to the bug log this was fixed in 2020, but the bug wasn't
closed for reasons that are unclear. Close it now.
--
Arto Jantunen
--- End Message ---
