“Please do not make it public” (Tencent’s Sogou Input Method) • Hacker News Board

Re: “Please do not make it public” (Tencent’s Sogou Input Method)

#41

Post by drekipus » Thu, Aug 10, 2023, 8:12 AM UTC

netsharc wrote: post #27

015a wrote: post #25

Earlier quoted context omitted.

Because they said it essentially as soon as the vulnerability is reported. That's an entirely reasonable thing to ask for; don't make this public, we're working on it. And its a totally normal allowance from security researchers. The title induces readers into thinking that they said this in some other context. Example 1: They aren't working toward fixing it, don't release this, lets just keep it hush hush. This isn'…

Yeah, kinda disappointing that the CitizenLab folks are exploiting the (I presume) non-mastery of subtle English of the developers to create a "clickbait" title. If they were English speakers they would've written something along the lines of "We thank you that you respected the vulnerability disclosure policy and notified us. We expect you'll continue respecting the policy and not publish this vulnerability before w…

I agree that it's a miscommunication but batting for citizenlab here, it's just an all-round misunderstanding of culture and language.

Chinese culture had a very strong "save face" mentality, especially big companies that have much government involvement. So they aren't going to admit fault or indicate that they have to do something.

The correct response to tencent's initial response, was to say that you are looking for status update and will disclose vulnerability by X time. Please let us know when the issue has been fixed.

Re: “Please do not make it public” (Tencent’s Sogou Input Method)

#42

Post by newaccount74 » Thu, Aug 10, 2023, 11:50 AM UTC

est31 wrote: post #19

newaccount74 wrote: post #5

Earlier quoted context omitted.

My experience with TLS is that it is not trivial to use. Understanding how to use eg. OpenSSL APIs correctly to ensure that a connection is secure, the certificates are valid, etc. is not trivial. The APIs are poorly documented, hard to use, and many examples you can find are outdated (some OpenSSL APIs return different numbers on success/failure depending on version). The platform native libraries are not much bette…

For the deprecated TLS algorithms, just use a bunch of reverse proxies at the front using the latest Debian, CentOS, or Ubuntu LTS, with mostly default settings. For OpenSSL, app developers don't need it. There is OS builtin libraries to do http requests (which is what was done here). As for certificates, there is plenty of solutions allowing for auto-renewal. It's very easy to set up using automation.

> There is OS builtin libraries to do http requests

If all you want to do is fetch an URL from a public HTTPS server, then I agree.

If you want to do anything even slightly more complex (eg. pin a specific cert, or use TLS with a protocol other than HTTPS) then the built in APIs are almost as bad as OpenSSL (at least on macOS/iOS, I don't know other platforms).

> As for certificates, there is plenty of solutions allowing for auto-renewal.

It's not a problem on the server side. It's a problem on the client side when the root certs expire. It puts an expiration date on your software.

Re: “Please do not make it public” (Tencent’s Sogou Input Method)

#43

Post by manuelabeledo » Thu, Aug 10, 2023, 12:59 PM UTC

lucubratory wrote: post #36

manuelabeledo wrote: post #15

Earlier quoted context omitted.

> They could be rightly suspicious of a western TLS implementation but discovered the pitfall of writing their own. Could have also been intentional. They could have deployed TLS with some cipher of Chinese origin, not like Chinese companies haven't done this before [0] [0] https://ciphersuite.info/cs/TLS_SM4_GCM_SM3/

If there's a zero day that's been embedded in a protocol by the NSA or actively used by the NSA, I normally wouldn't expect it to come from the actual encryption process itself. It would be something that choosing your own cipher wouldn't fix, because it would be about compromising security on the software level rather than the encryption level. There's a very good reason the PRC won't allow compromised Cisco routers…

> … actively used by the NSA …

So the NSA would purposefully embed an exploitable bug in a cipher they themselves use?

> … it would be about compromising security on the software level rather than the encryption level

Those are two very different things. A cipher could very well be exploitable. What you are talking about is the implementation.

In other words, a vulnerable cipher would be exploitable regardless of the implementation.

It is not the case, though. They tried to deploy their own protocol on top of a well known cipher.