Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PR_END_OF_FILE_ERROR - Secure Connection Failed #36

Closed
honzagit opened this issue Mar 12, 2023 · 6 comments
Closed

PR_END_OF_FILE_ERROR - Secure Connection Failed #36

honzagit opened this issue Mar 12, 2023 · 6 comments

Comments

@honzagit
Copy link

Hello,

the device search stops immediately so I can't find my wedo 2.0 device. The scratch-link is resetting session immediately after TLS Hello.

I am running firefox 111.0 on
$ cat /etc/issue
Ubuntu 22.04.2 LTS \n \l
with python 3.10

this might be same as #35
but not affected by #34

Installed as root:
1)
apt install bluez libbluetooth-dev libnss3-tools libcap2-bin python3-pip libglib2.0-dev python3-bluez python3-websockets

  1. pyscrlink-0.2.6 with bluepy, and older version later too (below):
    Requirement already satisfied: websockets in /usr/lib/python3/dist-packages (from pyscrlink==0.2.5) (9.1)
    Requirement already satisfied: pyOpenSSL in /usr/lib/python3/dist-packages (from pyscrlink==0.2.5) (21.0.0)
    Requirement already satisfied: pybluez in /usr/lib/python3/dist-packages (from pyscrlink==0.2.5) (0.23)
    Requirement already satisfied: bluepy in /usr/local/lib/python3.10/dist-packages (from pyscrlink==0.2.5) (1.3.0)
    Installing collected packages: pyscrlink
    Successfully installed pyscrlink-0.2.5

  2. set rights
    $ bluepy_helper_cap
    Set capacbility 'cap_net_raw,cap_net_admin' to /usr/local/lib/python3.10/dist-packages/bluepy/bluepy-helper
    and verified
    sudo getcap /usr/local/lib/python3.10/dist-packages/bluepy/bluepy-helper
    /usr/local/lib/python3.10/dist-packages/bluepy/bluepy-helper cap_net_admin,cap_net_raw=eip

  3. step 2 has been tested also as user, so both pyscrlink and bluepy were stored in home dir, ...same issue
    $ python3 ./.local/lib/python3.10/site-packages/pyscrlink/bluepy_helper_cap.py
    Set capacbility 'cap_net_raw,cap_net_admin' to /home/user/.local/lib/python3.10/site-packages/bluepy/bluepy-helper


The symptoms:

  • Scratch search dialog is immediately done with message "Make sure you have Scratch Link installed" and "Check Bluetooth Availability" (translation)
  • Firefox connection to https://device-manager.scratch.mit.edu:20110/ is closed with error:
    Secure Connection Failed
    An error occurred during a connection to device-manager.scratch.mit.edu:20110. PR_END_OF_FILE_ERROR

  • scratch-link is running without any new message as same user as firefox
    $ /usr/local/bin/scratch_link -d
    Print debug messages
    2023-03-12 20:34:08,165 set scan_seconds: 10.0
    2023-03-12 20:34:08,174 Certificate is ready in FireFox NSS DB: /home/user/.mozilla/firefox/xxxxxxx.default
    2023-03-12 20:34:08,181 Certificate is ready in FireFox NSS DB: /home/user/.mozilla/firefox/xxxxxx.default-release
    2023-03-12 20:34:08,188 Certificate is ready for Chrome
    2023-03-12 20:34:08,556 Started scratch-link
  • certs were regenerated
    2023-03-12 20:04:21,899 Generated certificate: /home/user/.local/share/pyscrlink/scratch-device-manager.cer
    2023-03-12 20:04:21,899 Generated key: /home/user/.local/share/pyscrlink/scratch-device-manager.key
    2023-03-12 20:04:21,908 Old certificate is in /home/user/.mozilla/firefox/xxxxxxx.default.
    2023-03-12 20:04:21,908 Add the new certificate to /home/user/.mozilla/firefox/xxxxxxx.default
    ...
  • I am not using firefox from snapstore, so there is no issue with paths (LEGO boost #34)
  • Connection is closed same way from edge (where should be no certificate), I believe it is closed before a security risk warning
  • it is translated to local host
    ;; ANSWER SECTION:
    device-manager.scratch.mit.edu. 900 IN A 127.0.0.1
  • scratch-link is listening
    $ netstat -tna | grep 20110
    tcp 0 0 127.0.0.1:20110 0.0.0.0:* LISTEN
  • wireshark of scratch is same like wireshark of direct connection to device-manager from firefox:
    when "start searching" is pressed, few packets to establish connection, TLSv1 Client Hello, answered by RST
  • behavior is same regardless "LPF2 Smart Hub 2" device is paired or not

Thanks for your ideas

@honzagit
Copy link
Author

The ciphers proposed by Hello are below

  • python3-websockets were installed at version (9.1-1),
  • libnss3-tools (2:3.68.2-0ubuntu1.2) ...
  • If scratch_link is expecting https, I have no ther idea why should it answer by tcp rst...

Internet Protocol Version 4, Src: 127.0.0.1, Dst: 127.0.0.1
Transmission Control Protocol, Src Port: 58760, Dst Port: 20110, Seq: 1,
Destination Port: 20110
....
Transport Layer Security
TLSv1 Record Layer: Handshake Protocol: Client Hello
...
Handshake Protocol: Client Hello
Handshake Type: Client Hello (1)
Length: 508
Version: TLS 1.2 (0x0303)
...
Cipher Suites Length: 36
Cipher Suites (18 suites)
Cipher Suite: TLS_AES_128_GCM_SHA256 (0x1301)
Cipher Suite: TLS_CHACHA20_POLY1305_SHA256 (0x1303)
Cipher Suite: TLS_AES_256_GCM_SHA384 (0x1302)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca9)
Cipher Suite: TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca8)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c)
Cipher Suite: TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d)
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
...
Extension: signature_algorithms (len=24)
...
Signature Hash Algorithms (11 algorithms)
Signature Algorithm: ecdsa_secp256r1_sha256 (0x0403)
Signature Algorithm: ecdsa_secp384r1_sha384 (0x0503)
Signature Algorithm: ecdsa_secp521r1_sha512 (0x0603)
Signature Algorithm: rsa_pss_rsae_sha256 (0x0804)
Signature Algorithm: rsa_pss_rsae_sha384 (0x0805)
Signature Algorithm: rsa_pss_rsae_sha512 (0x0806)
Signature Algorithm: rsa_pkcs1_sha256 (0x0401)
Signature Algorithm: rsa_pkcs1_sha384 (0x0501)
Signature Algorithm: rsa_pkcs1_sha512 (0x0601)
Signature Algorithm: ecdsa_sha1 (0x0203)
Signature Algorithm: rsa_pkcs1_sha1 (0x0201)
....

@kawasaki
Copy link
Owner

@honzagit Thanks for the precise report. This is weird. The "scratch_link -d" output stops with the message "Started scratch-link", then the issue looks happening at the https connection establishment between the browser and the scratch_link. This symptom looks new. As you found, the NSSDB path difference of Snap version of Firefox should not be a problem.

As a trial, I pulled out my old laptop in my drawer and installed Ubuntu 22.04 LTS. Then I tried pyscrlink with my micro:bit, but your issue was not recreated (other issue came unique to my laptop, but it is a different story). I tried both Snap version of Firefox (with NSSDB path change) and non-Snap version of Firefox, downloaded from Mozilla site. The symptom was same. With both Firefox, scratch_link printed the message "Start session for web socket path: /scratch/ble". Then the https connection was established successfully on my Ubuntu laptop.

I still have no idea what is happening. One thing which might worth checking is the certificate in Firefox NSSDB and that pyscrlink uses. As for the former,

$ certutil -L -d ./.mozilla/firefox/XXXXXX.default/ -n device-manager.scratch.mit.edu -a

will show it. As for the latter, you can cat ./.local/share/pyscrlinkg/scratch-device-manager.cer. If these are different, that would be the cause of the failure. If these are same, then I really have no idea...

@honzagit
Copy link
Author

I would say that the certs are same even diff does not think so...
BTW it is interesting that lines -----BEGIN/END CERTIFICATE----- are considered same even by diff...
thank for your effort!

diff ./.local/share/pyscrlink/scratch-device-manager.cer <(certutil -L -d ./.mozilla/firefox/xxxxxxx.default/ -n device-manager.scratch.mit.edu -a)
2,16c2,16
< MIIC+jCCAeKgAwIBAgIBADANBgkqhkiG9w0BAQsFADApMScwJQYDVQQDDB5kZXZp
< Y2UtbWFuYWdlci5zY3JhdGNoLm1pdC5lZHUwHhcNMjMwMzEyMTkwNDMwWhcNMzMw
< MzA5MTkwNDIxWjApMScwJQYDVQQDDB5kZXZpY2UtbWFuYWdlci5zY3JhdGNoLm1p
< dC5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCghd/UqMcKOs9s
< IUJ0R0kO1oRtMp0TlT9gGjShBuWC3SznlESNgngtWaAMCZ3r2mwb0mwApnWG5vZA
< M0xysj4kC1kbr4zn1MeTgepdbSR4Qt6jUl0N0s63Ug8md38V+awMEdSazDdSEPXg
< yXhuV5gJPg8O86O6PzBd32aQOPJ8qnWK39X/ppVjentH7q4BWib47oIRsqOs+8dw
< 4BXD50kh5XsNl8jrnEbkK69vCPhjUSttMSL+fYeCBgaLlP+0XYQUVxUxvuHNYV4y
< AS+nToYDrxkEKZa8suHmD1UfbR2fkiExLEvgJwHHRh6EQnr5q9r82Jz9A0ixuay7
< oFALEk3rAgMBAAGjLTArMCkGA1UdEQQiMCCCHmRldmljZS1tYW5hZ2VyLnNjcmF0
< Y2gubWl0LmVkdTANBgkqhkiG9w0BAQsFAAOCAQEAPFLHZHa6CO8UdGPxOY2z08an
< WPOQJXuH66LlNOdq5yvZknqa4ja1SV4a5PpjA6puKK+MbL0eiG9LnW+L7AJTNBfk
< ISFtbTwhHV68if7nlPJDB+ORGxE4Lc6DkwZOzOwoU6e5ZTI50ehtCqgRvcqB82Xo
< 9ncFNIY78Nc9yM8jYgh3/gGn2SD1MHTCYlJaL30+KD0L1L0m3WTJKvwM5kEJxJox
< gezk+R5KjS2Ks7A/NIEqMumYv0Dtf/GPc5s8A2G66wep2+iT0xBrMpVQ/7zQNo6K
---
> MIIC+jCCAeKgAwIBAgIBADANBgkqhkiG9w0BAQsFADApMScwJQYDVQQDDB5kZXZp
> Y2UtbWFuYWdlci5zY3JhdGNoLm1pdC5lZHUwHhcNMjMwMzEyMTkwNDMwWhcNMzMw
> MzA5MTkwNDIxWjApMScwJQYDVQQDDB5kZXZpY2UtbWFuYWdlci5zY3JhdGNoLm1p
> dC5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCghd/UqMcKOs9s
> IUJ0R0kO1oRtMp0TlT9gGjShBuWC3SznlESNgngtWaAMCZ3r2mwb0mwApnWG5vZA
> M0xysj4kC1kbr4zn1MeTgepdbSR4Qt6jUl0N0s63Ug8md38V+awMEdSazDdSEPXg
> yXhuV5gJPg8O86O6PzBd32aQOPJ8qnWK39X/ppVjentH7q4BWib47oIRsqOs+8dw
> 4BXD50kh5XsNl8jrnEbkK69vCPhjUSttMSL+fYeCBgaLlP+0XYQUVxUxvuHNYV4y
> AS+nToYDrxkEKZa8suHmD1UfbR2fkiExLEvgJwHHRh6EQnr5q9r82Jz9A0ixuay7
> oFALEk3rAgMBAAGjLTArMCkGA1UdEQQiMCCCHmRldmljZS1tYW5hZ2VyLnNjcmF0
> Y2gubWl0LmVkdTANBgkqhkiG9w0BAQsFAAOCAQEAPFLHZHa6CO8UdGPxOY2z08an
> WPOQJXuH66LlNOdq5yvZknqa4ja1SV4a5PpjA6puKK+MbL0eiG9LnW+L7AJTNBfk
> ISFtbTwhHV68if7nlPJDB+ORGxE4Lc6DkwZOzOwoU6e5ZTI50ehtCqgRvcqB82Xo
> 9ncFNIY78Nc9yM8jYgh3/gGn2SD1MHTCYlJaL30+KD0L1L0m3WTJKvwM5kEJxJox
> gezk+R5KjS2Ks7A/NIEqMumYv0Dtf/GPc5s8A2G66wep2+iT0xBrMpVQ/7zQNo6K

@markakis-sch
Copy link

I would say that the certs are same even diff does not think so... BTW it is interesting that lines -----BEGIN/END CERTIFICATE----- are considered same even by diff... thank for your effort!

The certutil exports the certificate with the character ^M (carriage-return) at the end of each line.
This is why the diff command shows difference between ./.local/share/pyscrlink/scratch-device-manager.cer (no ^M character) and the exported ./.mozilla/firefox/xxxxxxx.default/

If you export the certificate to file and open it with vi, you will see it.
certutil -L -d ./.mozilla/firefox/XXXXXX.default/ -n device-manager.scratch.mit.edu -a > /tmp/test.cer
vi /tmp/test.cer

@kawasaki
Copy link
Owner

As discussed in the issue #35, the old version of websockets could be the cause. @honzagit when you have time, please try the guides in #35.

@honzagit
Copy link
Author

It is solved
I was affected by #35, so

sudo apt remove python3-websocket
pip install pyscrlink

moved me forward (uninstall also yt-dlp)
SSL session to device manager was established (with: Failed to open .... You need a WebSocket clien)
I tried on two notebooks, but both afected by #29

so:
sudo hciconfig hci0 down && sudo hciconfig hci0 up
finally helped...

Many Thanks!!!!!!!!!!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants