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.

Sign up for GitHub

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

Jump to bottom

Signal fails to connect from university's network #3275

Closed
1 task done
Natanji opened this issue Mar 29, 2019 · 7 comments
Closed
1 task done

Signal fails to connect from university's network #3275

Natanji opened this issue Mar 29, 2019 · 7 comments
Labels
Centralized Change Needed Need Information

Comments

@Natanji
Copy link

Natanji commented Mar 29, 2019 •
edited
Loading

  • I have searched open and closed issues for duplicates

Bug Description

Since two days, I have been unable to use Signal from my university's network (specifically, I am in the subnet /24). This applies to both the WiFi from my Android, and Signal-Desktop installed to my office PC that also connects to the internet via the university's network. It seems that the Signal server just drops all traffic from here:

$ curl https://textsecure-service.whispersystems.org/
curl: (28) Operation timed out after 300169 milliseconds with 0 out of 0
bytes received

I have checked my university's firewall policy and Signal is not on there; I can also verify that the IPs are not blocked from here because funnily enough, the Signal server DOES in fact respond on the HTTP port:

$ curl http://textsecure-service.whispersystems.org/
<html>
<head><title>400 The plain HTTP request was sent to HTTPS port</title></head>
<body bgcolor="white">
<center><h1>400 Bad Request</h1></center>
<center>The plain HTTP request was sent to HTTPS port</center>
</body>
</html>

So this is why I don't think the problem lies with my university, but on the other side.

I am aware that this is not a problem with Signal-Desktop itself, but most likely with the Signal server/some configuration or blocking in your Nginx. I am still reporting this here because I noticed the problems first on Desktop, and while I can switch my Android to mobile data, I cannot do the same for my office PC obviously. I hope you can show/forward this to the appropriate OWS server admins, if applicable, or point me to where I (or my university's network admins) can report this.

Steps to Reproduce

  • Open Signal-Desktop

Actual Result:

Expected Result:

  • Signal-Desktop connects to the server and works

Platform Info

Signal Version: 1.23
Operating System: Ubuntu 18.04.1 LTS
Linked Device Version: 4.36.2

Link to Debug Log

https://debuglogs.org/89e338006f876a0eda1b77c27da8ecdac7a2410c5bdaac60130ed90abe1c657e
@minnmann
Copy link

Does your university network use some kind of proxy?

There have been several issues reported about such networks. E.g. one of my contacts is at a research facility, which uses a proxy, causing some trouble every now and then (failed attachment downloads etc. see #2985, #3032).

I am also in a (German) university subnet (without proxy) and my office PC (connected via ethernet) never had any trouble. So it would be quite strange, if a comparable university network is blocked on the server side.

Just some isseus for reference with further information (if the proxy issue should be the case):
#1632.
The environment variables that have to be set are described here: #1855

@Natanji
Copy link
Author

Natanji commented Mar 29, 2019 •
edited
Loading

No, my university definitely doesn't use any kind of proxy. I am directly connected to the internet with an IP from /24, I can see that address in the logs of my own servers when I connect to them. Also note that up until yesterday everything worked absolutely fine; if this was an issue with the university adding a proxy all of the sudden, then a LOT of software would not longer work/need to be reconfigured to use the proxy, but nothing like that happened. It's only Signal.

@minnmann
Copy link

You are absolutely right. That definitely does not sound like it is related to some kind of proxy.

As the issues #2985, #3032 mostly likely also have been caused due to some misconfiguration of the server (at least that is my assumption, because it just worked again for all affected people without any changes on the client sides), a server side fault might of course have happened again.

@0xConstant1
Copy link

Have you tried using a VPN to login through that network? Could mean they're blocking signal's servers if you're able to successfully

@Natanji
Copy link
Author

Natanji commented Mar 29, 2019

They are not blocking the servers, again, I can connect via HTTP just not HTTPS. Outgoing blocks would also typically not lead to packages just being dropped, the gateway/its firewall would instead reject it. Of course it would work via VPN, I don't even have to try that, it obviously works when the traffic originates from a different network (doesn't matter if it's VPN or my mobile data connection).

@scottnonnenberg-signal
Copy link
Contributor

What do you get with a curl -v?

$ curl -v https://textsecure-service.whispersystems.org/
*   Trying 35.169.3.40...
* TCP_NODELAY set
* Connected to textsecure-service.whispersystems.org (35.169.3.40) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/cert.pem
  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (OUT), TLS alert, Server hello (2):
* SSL certificate problem: self signed certificate in certificate chain
* stopped the pause stream!
* Closing connection 0
curl: (60) SSL certificate problem: self signed certificate in certificate chain
More details here: https://curl.haxx.se/docs/sslcerts.html

curl performs SSL certificate verification by default, using a "bundle"
 of Certificate Authority (CA) public keys (CA certs). If the default
 bundle file isn't adequate, you can specify an alternate file
 using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
 the bundle, the certificate verification probably failed due to a
 problem with the certificate (it might be expired, or the name might
 not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
 the -k (or --insecure) option.
HTTPS-proxy has similar options --proxy-cacert and --proxy-insecure.

Maybe some of your university's new traffic inspection chokes on our self-signed certificates?

@Natanji
Copy link
Author

Natanji commented Apr 1, 2019

So I couldn't answer because of not being at my university for the weekend, but since returning today, the problem is fixed. If you didn't change anything on your side, I suspect my university did... the idea with the traffic inspection is a possible idea, yea.

This can be closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Centralized Change Needed Need Information
Milestone
No milestone
Development

No branches or pull requests
4 participants
@Natanji @minnmann @0xConstant1 @scottnonnenberg-signal