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
