Signal's TLS Proxy Failed to Be Probing Resistant | Hacker News Reader

Signal's TLS Proxy Failed to Be Probing Resistant

github.com

114 pointsrrryougi42 comments

While the authors of this definitely didn't handle this well, I'd argue it's a pretty severe weakness and the tool shouldn't have been released in this state. Active probing has been observed in the wild [1] and pretty much all tooling in the space handles it in their threat model [2], so its naive to not consider it.

I get why the signal team wanted something to use HTTPS, even networks with completely insane firewalls accept it and they get to reuse existing domain fronting code, but existing tools continues to viable in Iran and would have made much more sense in the circumstances.

[1] https://blog.torproject.org/learning-more-about-gfws-active-...

[2] https://github.com/Yawning/obfs4/blob/master/doc/obfs4-spec....

Moxie deserves an ACM award for his contributions to crypto but he shouldn't be leading the project. Maybe posting on the Discourse forum was the right thing to do here. I just see a lot of hostility between Signal employees and those wishing to make the project a little bit better.

That so-called hostility seems to be pretty one-sided IMO. The response from the Signal dev seemed pretty calm and reasonable, but OP seemed to take it as a personal insult for no reason.

Some projects don't want to discuss issues on GitHub and prefer a forum they have control over; that's totally understandable.

That's those projects I don't report issues to and rather maintain local patches for.

I'm not gonna sign up to the fivetrillionth forum or bug tracker for your special snowflake software. If you don't allow bug reports via github issues, you won't get mine.

They have been ignoring or brushed off the importance of reported privacy related issues for years. Doesn't built trust to use Signal for me personally

Could you be more specific about the issues they’ve been ignoring or brushing off?

For a year, they have been reporting reports of the issue wit the IME keyboards. See: https://community.signalusers.org/t/signal-should-warn-users...

If you are serious about privacy and secure messenger, you just can't brush off such issues.

[1] https://twitter.com/realsexycyborg/status/119769536810582425... [2] https://community.signalusers.org/t/signal-should-warn-users... [2] https://www.theverge.com/22249391/signal-app-abuse-messaging...

That's not a problem of Signal but of insecure IME-Apps.

Of course they’re brushing this off, there’s simply nothing they can do to solve the problem of compromised platforms.

Signal should focus on problems they can realistically solve.

Adding a warning is not unrealistic and unsolvable.

A warning was added a few weeks ago :)

How long did he wait for the signal forum to approve his account? The guy, or girl, seems rather aggressive. It's mentioned they've not slept in a while...

The issue mentions time from reporting to this new GH issue to be just 4 hours. So it has to be less than that.

It got approved fairly quickly. It was a false positive (see my link in main thread) with their spam detection (DuckSoft copy pasted the post so flagged as "type too fast").

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

I am DuckSoft on GitHub and I prove my identity by GPG signing this message.

I am not typing too fast, nor pasting all my stuffs into the comment area. I just put a link to the GitHub issue. The discussion board even automatically extracted title and abstract for me, where I thought, 'pretty cool huh'.

Then I got banned. -----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEE2H0QtOEy/6QN7CMrejqfpuT9So0FAmAdx9IACgkQejqfpuT9 So1KrQf+M8VzJBj4FgNZB/KZZ/suxNBF9DEkcfR66mwf/YzGGK9Gf2QDBqNoHUJs jJGvRai4ygqtZE3oX3GZmkjRT8LzEiNgmOM+B39SehL7F9rhMGz4lHMrRV5ZnSxp w5ALHSs3L6Gyg5hwNOQV73+STg9Vc2TsWSCS+Xr+BuNYbbLwiKWV9M1pxOynaWx0 J5+JswXaZkEONcKyGKbwc2FrgH1EXRgv+TipHucAkz+1HVMRd9NZ5W38vjASWEwO dEXXmCWyH8rQ69rLU+M7lXiKY0IBVrvVirzC97TpS22A74FDTdEG4xpGHSzPaDFp 3DRJvymGOlHDqhlotR8ox1ndFPzR9A== =ib+f -----END PGP SIGNATURE-----

It sounds like a mistake, the robots incorrectly tagged you. I wouldn't interpret any ill will because of it. Also sounds like they approved your account shortly after so it's hard to see anything that negative here...

So guys I've been blocked. See: https://web.archive.org/web/20210206065553/https://community...

My experience with the Signal team in issues and their community has been about the same.

They're generally dismissive, especially so about design problems that cause a big amount of bugs that are strewn throughout Signal, like their handling of message timestamps/sync and dismissal of the IME concerns.

Agreed, it is why I prefer Matrix. World of difference.

Man I feel bad for the signal devs. Keep fighting the good fight, and thank you!

Wow this guy seems like he's an asshole.

Although i do wonder why signal didn't reuse the work tor did with obfuscated bridges.

For people curious, it looks like they are discussing it in the community but only the mod is involved and I don't think they (Herohtar) are an employee. While the block was unintentional this doesn't seem like the right way to handle the situation and Moxie should have been clearer and that would have avoided the issue. It is easy to interpret the response given as being brushed off.

TLDR: DuckSoft got autobanned because they typed too fast (copy pasted their post into the forum) and had a false positive from spam detection. No comment yet from devs on issue.

Edit: removed my personal preference that seems to be being confused as saying Signal should use GitHub. Signal can do what they want, that's fine. But be clear.

https://community.signalusers.org/t/tls-proxy-server-unable-...

> Also, honestly, why not use GitHub issues. I find issues useful.

Some people would prefer to use their own issue tracker or discussion forum. I don't see that as strange at all, given that with GH issues you don't have full control over the data or experience.

You could mirror, making your project accessible while not risking data loss.

People who run the project get to pick the bug tracker. Its really next level entitlement to not let maintainers choose the place they track bugs.

That's fine. I'm not sure why that means they shouldn't be more clear. The GH comment was a preference. The problem here is that the message Signal sent sounds generic and can easily be interpreted as brushing the person off. They clearly interpreted it that way.

Why shouldn't people who post in the wrong place get a generic message?

Afaict, its not like they are reporting a drop everything issue. Did anyone actually think that a determined adversary would not be able to distinguish between one of their proxies and a generic TLS server, given sufficient resources?

> Why shouldn't people who post in the wrong place get a generic message?

Because people aren't clairvoyant and it is reasonable to assume that people that post stuff on GitHub accept issues, just like the main Signal account does. The generic message, without original clarity in how to note an issue, is easy to interpret as being ignored. Especially as they had a false positive ban being flagged as spam. I understand Signal's pov and I understand DuckSoft's. I think Signal has the higher responsibility in clarity than some random person trying to note a flaw they found.

Look, you can like Signal and still think they made the wrong move. I've used it every day for years and converted the majority of my friends. No one expects Signal to be perfect.

> Because people aren't clairvoyant

Luckily they have a generic message to read. No clairvoyancey required.

I'm not defending signal here because i just like signal. Almost any other open source project would have responded the same way. Many would probably have been less polite about it. If you send a personalized note to everyone who reports a bug incorretly, you won't have any time to actually fix bugs.

Edit: i agree though that the false positive spam ban is a bit unfortunate. Shit happens sometimes. I maintain the generic message was totally reasonable and they should not do anything different in that regard if they could do it over again. The spam ban however was understandable but obviously should not have happened.

The GH issue poster was overreacting in multiple steps: first by getting the generic reply, then thinking that making issues was disabled to "get rid of him" (or what not). He/she should get some sleep.

It is their choice, but everyone knows a project not on GH gets less visibility and fewer reports and contributors because of that decision. I know some projects do it to minimize public interaction, they feel raising the barrier improves the quality ratio of issues.

What is that PoC in the issue doing? They check e which is not set after first line in the function:

    func send(addr, server, sni string) int {
     c0, e := net.Dial("tcp", addr)
     if e != nil {
      log.Fatal(e)
     }
    
     c1 := tls.Client(c0, &tls.Config{
      ServerName:         server,
      InsecureSkipVerify: true,
     })
    
     c2 := tls.Client(c1, &tls.Config{
      ServerName:         sni,
      InsecureSkipVerify: true,
     })
     c2.SetDeadline(time.Now().Add(2 * time.Minute))
     s := fmt.Sprintf("GET / HTTP/1.1\r\nHost: %s\r\nUser-Agent: curl/7.68.0\r\n\r\n", sni)
     //b := make([]byte, 4096)
     l, _ := c2.Write([]byte(s))
     log.Println(l)
     if e != nil {
      return 0
     }
     log.Printf("%s->%s->%s\n", addr, server, sni)
     return l
    }

I still think they should have used layer 4 CDN endpoints that use generic names on several of the CDN providers that support L4. It would be endless whack-a-mole to block that. Not perfect, but not perfect is probably useful enough for those impacted by blocks as it would mean periodic latency vs. being locked out entirely. Moxie, if you are reading this, to mitigate some of the probing or fingerprinting, consider borrowing some of the code from sslh [1] and I acknowledge this would be an endless arms race.

[1] - https://github.com/yrutschle/sslh

This seems like a relatively easy issue to fix. If they included a "password" to the proxy (and stuck it on the share URL) then the proxy can reject requests unless the password authentication passed. This way it would look like any other HTTPS site that was password protected. Only if you know the password would you get proof that the other end was connected to Signal.

Things has been updated. Signal banned @studentmain and @ducksoft from their GitHub organzation.

Reply on news.ycombinator.com