[00:00.000 --> 00:02.020]  All right, quiz time.
[00:02.400 --> 00:05.920]  What were the most popular or most downloaded apps in 2023?
[00:06.200 --> 00:06.940]  Just shout them out.
[00:10.620 --> 00:11.180]  Okay.
[00:12.540 --> 00:13.100]  Awesome.
[00:13.900 --> 00:15.280]  So here are the answers.
[00:15.600 --> 00:16.640]  You guys are great.
[00:16.800 --> 00:19.480]  I heard a lot of the apps here shouted out.
[00:20.340 --> 00:30.240]  And I think the point I sort of wanted to make is that when we say global, often what we actually mean is global except for China.
[00:30.240 --> 00:30.360]  Yeah.
[00:30.920 --> 00:34.940]  As an example, the data source I got this data from has like this section.
[00:35.080 --> 00:40.960]  It says Instagram was the most downloaded app globally in 2023 with 696 million downloads.
[00:41.220 --> 00:45.320]  And then if you like scroll down like this two paragraphs down, it says we chat 1 billion downloads.
[00:45.840 --> 01:05.720]  So it's just like... and I think we do this sort of out of practical need to do it because the Chinese Internet has, for one reason or another, developed on its own, you know, due to the Great Firewall, due to sanctions, and sort of become its own behemoth and its own ecosystem.
[01:06.660 --> 01:15.360]  But I also want to note that this has caused a lot of bias in security research community, in the Internet security community.
[01:16.420 --> 01:21.160]  Over the last 20 years, we've done an amazing job of encrypting the Internet.
[01:21.160 --> 01:27.160]  Thanks to Let's Encrypt, thanks to a lot of advocacy done by a lot of the amazing groups here.
[01:27.440 --> 01:34.860]  At this point, we are at 80% of all page loads on Firefox loaded over HTTPS, which is absolutely incredible.
[01:37.820 --> 01:41.280]  However, I do want to add that asterisk here.
[01:41.960 --> 01:47.920]  How many of these apps do you think are always using HTTPS and TLS?
[01:48.220 --> 01:49.680]  And this is a rhetorical question.
[01:49.920 --> 01:53.420]  We actually are in the middle of doing this larger study.
[01:53.580 --> 01:55.980]  And so we looked through our data, and this is the answer.
[01:58.000 --> 02:12.360]  Okay, so essentially, all of the apps that were developed in China, except for Douyin, which is like the Chinese version of QuickTalk, we're not always using HTTPS or TLS to send network data.
[02:13.040 --> 02:15.840]  But they're also not not encrypting.
[02:15.980 --> 02:19.020]  Like, they're not just sending all of the data over HTTP.
[02:19.340 --> 02:24.880]  They're using proprietary cryptography, which is absolutely terrible.
[02:25.080 --> 02:31.340]  As you might have guessed, you might have sort of predicted where this talk is going.
[02:32.660 --> 02:36.020]  So for some reason or another, this like mantra, right?
[02:36.020 --> 02:44.660]  Like, don't roll your own crypto, is not really being taken seriously by these very large, very well-resourced, and very smart Chinese companies.
[02:45.920 --> 02:55.120]  And so today, we're going to be presenting three case studies of proprietary cryptography in Chinese applications.
[02:56.340 --> 02:58.300]  We're going to talk about the cryptography.
[02:58.300 --> 03:03.020]  We're also going to talk about what kind of data is being protected with this cryptography.
[03:03.020 --> 03:10.160]  And while we talk about these things, I also just want you to think about the scale of these apps.
[03:10.480 --> 03:18.220]  You know, even like with the browsers that are popular in China, 400 million plus users, that's larger than the entire population of the United States.
[03:19.580 --> 03:20.140]  Okay.
[03:20.140 --> 03:22.500]  So first, I'll be talking about WeChat.
[03:22.840 --> 03:26.320]  Zoe will be talking about keyboards that are popular in China.
[03:26.320 --> 03:30.140]  And Jeff over here will be talking about browsers that are popular in China.
[03:33.660 --> 03:34.460]  I'm sorry.
[03:35.900 --> 03:37.660]  I'll try to speak more clearly.
[03:39.740 --> 03:40.380]  All right.
[03:40.520 --> 03:42.180]  So first, we'll be talking about WeChat.
[03:44.160 --> 03:51.240]  If you look at WeChat traffic, all of the WeChat traffic is like HTTP post request.
[03:51.240 --> 03:55.220]  We have this weird URL and it says MMTLS in it.
[03:55.500 --> 03:59.660]  And the body of the post request is a bunch of encrypted data.
[04:00.100 --> 04:00.840]  I'm going to lower this.
[04:04.470 --> 04:06.210]  It's just a bunch of encrypted data.
[04:06.730 --> 04:15.410]  And so the first time I saw this, it was like in 2017, I was looking at WeChat traffic and I was like, what is this?
[04:15.510 --> 04:21.670]  And so I had two main questions that I've been able to work on with my colleagues here.
[04:21.670 --> 04:23.730]  How secure is the cryptography?
[04:23.890 --> 04:24.730]  What does it look like?
[04:25.090 --> 04:31.930]  And then what sort of analytics data is WeChat collecting and sending over the network using this cryptography?
[04:32.150 --> 04:35.570]  What is the data that is being protected by the proprietary cryptography?
[04:37.270 --> 04:40.470]  And so first we looked at the cryptographic protocols themselves.
[04:42.050 --> 04:45.270]  You know, how does WeChat request encryption work?
[04:45.450 --> 04:47.430]  And the answer is, it's a huge mess.
[04:47.570 --> 04:49.010]  It's a bunch of spaghetti code.
[04:49.010 --> 04:54.090]  It's at least three to five different cryptosystems developed over 12 years or something.
[04:55.050 --> 04:57.690]  And all requests are actually encrypted twice.
[04:58.470 --> 05:03.530]  And each of these cryptosystems have their own keys that are stored separately.
[05:03.690 --> 05:05.240]  And they have their own handshakes.
[05:05.850 --> 05:10.230]  And they all are, you know, taking like one of them is in native code and one of them is in Java.
[05:10.230 --> 05:17.590]  And so to sort of simplify it, the first layer of encryption we refer to as business layer encryption.
[05:17.590 --> 05:21.510]  And this term is sort of translated from some blog post content put out.
[05:21.910 --> 05:24.410]  And the second layer is MMTLS encryption.
[05:24.590 --> 05:26.690]  And that's the encryption we see on the wire.
[05:28.010 --> 05:32.210]  I'm not going to get into too many of the details because we have a lot to go through.
[05:32.210 --> 05:36.390]  But here is the laundry list of problems we found with both layers of encryption.
[05:36.750 --> 05:48.290]  The other thing I want to note is that the business layer encryption was actually being used prior to 2016, like as the sole layer of encryption for a long time.
[05:48.470 --> 05:53.090]  And in 2016, then they also added this new layer of MMTLS encryption.
[05:53.090 --> 05:57.770]  So the business layer encryption is like sort of sophomoric cryptography.
[05:58.490 --> 06:01.590]  MMTLS is a fork of TLS, but worse.
[06:02.230 --> 06:06.010]  And so we reported all of these things to Tencent.
[06:06.270 --> 06:11.990]  They sort of said, we're going to improve the business layer encryption, but we're going to keep MMTLS encryption.
[06:12.310 --> 06:17.910]  So that's just a note for security researchers who are interested in like further studying these protocols in the future.
[06:18.090 --> 06:19.090]  They will still be used.
[06:20.510 --> 06:21.050]  Okay.
[06:21.570 --> 06:22.330]  Moving on.
[06:22.510 --> 06:26.670]  What kind of data is WeChat collecting and sending using MMTLS?
[06:26.890 --> 06:32.790]  And there's just like so many different functionalities of WeChat that we just looked at WeChat mini programs as a case study.
[06:34.130 --> 06:36.470]  What are WeChat mini programs?
[06:36.730 --> 06:37.390]  Just really quick.
[06:37.770 --> 06:39.910]  So in WeChat, you can chat.
[06:40.110 --> 06:41.570]  You can look at posts.
[06:41.570 --> 06:51.590]  But you can also do things like call Ubers, buy stuff, play gambling games, and order food or look at your, you know, COVID contact tracing codes.
[06:52.450 --> 06:57.510]  I would liken it to a sort of Google Play or App Store within an app.
[06:57.630 --> 07:01.570]  So it's like a sort of application ecosystem within WeChat itself.
[07:03.270 --> 07:07.250]  The way that this is implemented is like a bad browser.
[07:07.730 --> 07:11.910]  So essentially, it's got like this fork of Chromium that's sitting inside WeChat.
[07:12.270 --> 07:15.050]  Let's say I'm Pinduoduo, which is like a shopping platform.
[07:15.270 --> 07:24.710]  Then I, as Pinduoduo, if I want to host a mini program on WeChat, I would send them a bundle of, you know, HTML, JavaScript, and CSS.
[07:25.730 --> 07:27.590]  WeChat would take that bundle and host it.
[07:28.270 --> 07:34.870]  One difference is, you know, of course, WeChat provides its own JavaScript APIs for people to call into.
[07:35.090 --> 07:41.890]  So if Pinduoduo wants to make a network request, for instance, it has to call wx.request.
[07:42.450 --> 07:45.770]  This then goes down to WeChat and the operating system it makes.
[07:45.970 --> 07:49.810]  One nice thing is that it enforces HTTPS on all network requests.
[07:49.810 --> 07:56.670]  And then it goes to Pinduoduo, the servers, you know, then the app can, the mini program can load the resources.
[07:57.990 --> 08:02.810]  But concurrently, we also see an MMTLS request sent to WeChat servers.
[08:02.950 --> 08:06.090]  So then this immediately became a very interesting case study for us.
[08:06.150 --> 08:08.630]  Like, why is it sort of doing both of these at the same time?
[08:09.070 --> 08:17.690]  And the answer is that all network requests during mini program usage are sort of also being forwarded to WeChat servers.
[08:17.690 --> 08:20.930]  So as an example, I was like on a shopping mini program.
[08:21.110 --> 08:24.930]  This is an example of a decrypted MMTLS request while I was shopping.
[08:25.070 --> 08:29.630]  You can see in yellow, like the search data string is what I put into the search bar.
[08:30.450 --> 08:31.730]  There's like click time.
[08:31.910 --> 08:36.790]  There's also like a live image of the thing that I was looking at.
[08:36.890 --> 08:40.130]  And then the title of the product that I was doing.
[08:42.210 --> 08:51.330]  So this is a program that we saw that was called WeChat Mini Programs Analytics, or WeFinC.
[08:51.950 --> 08:57.430]  And it sends data about mini program usage and browsing back to WeChat over MMTLS.
[08:57.910 --> 09:06.350]  By default, it's opt-in for all mini programs, all browsing activities sent, including like location, metadata, page details, etc.
[09:07.730 --> 09:11.210]  We did a study across like multiple mini program verticals.
[09:11.650 --> 09:14.030]  And it's just, yeah, it's just really bad.
[09:14.550 --> 09:17.950]  So this is the type of work that we would like to continue.
[09:18.710 --> 09:24.730]  The number of MMTLS users is on the similar order of magnitude as the number of TLS users.
[09:24.730 --> 09:28.210]  So it needs a lot more scrutiny from security researchers.
[09:28.590 --> 09:31.670]  It deserves just as much scrutiny as TLS.
[09:31.830 --> 09:34.970]  It's going to be in the foreseeable future.
[09:35.330 --> 09:42.210]  And studying these protocols will also continue to enable through privacy studies, such as the mini programs that we did.
[09:43.590 --> 09:49.450]  So unfortunately, like WeChat is pretty bust, but at least maybe like our keyboards are safe, right?
[09:49.450 --> 09:50.130]  Don't we?
[09:52.590 --> 09:54.370]  Uh, let's find out.
[09:56.270 --> 10:05.210]  So I'm going to be talking about some research that I did with these two into some popular cloud-based Chinese keyboard apps.
[10:08.490 --> 10:11.550]  Imagine a billion people around the world typing.
[10:11.850 --> 10:21.410]  And as they're typing, a network eavesdropper could be reading every character they write, including passwords, sensitive information, private messages, and more.
[10:22.990 --> 10:24.810]  What do all these people have in common?
[10:25.230 --> 10:29.970]  Well, they're users of some of the most popular cloud-based keyboard apps in China.
[10:32.230 --> 10:37.930]  We found in our research that eight out of nine vendors' keyboard apps revealed user keystrokes.
[10:38.190 --> 10:45.030]  And so as network eavesdroppers, we were able to intercept and completely reveal the contents of users' keystrokes in transit.
[10:47.250 --> 10:51.650]  But first, you might be wondering what these keyboard apps are all about.
[10:51.930 --> 10:55.250]  Why do so many people need a cloud-based keyboard app?
[10:55.850 --> 11:02.850]  Although many of us might be used to typing in Latin script, an alphabet of just 26 letters, typing in Chinese is a little bit different.
[11:03.290 --> 11:07.790]  Since there are tens of thousands of Chinese characters, they don't all fit on a keyboard.
[11:08.470 --> 11:12.310]  And so a cloud-based keyboard app makes it much easier to type in Chinese.
[11:13.350 --> 11:20.550]  And market research estimates that probably almost a billion users around the world are using specifically the apps that we analyzed.
[11:23.010 --> 11:33.350]  So I'm not going to go into the details of the vulnerabilities we found in every single app, but I will do one of the apps in detail, which is SoGoInputMethod, developed by Tencent.
[11:34.910 --> 11:48.550]  So we analyzed three different versions of the app and found that the iOS version didn't have any exploit that we were able to attack, but both the Windows and Android versions were vulnerable to a padding Oracle attack.
[11:51.460 --> 11:57.920]  So the way that SoGoInputMethod's encryption works is they have what's called an EncryptWall.
[11:58.500 --> 12:08.500]  And this is basically just an EncryptWall request is sent as an HTTP POST request in the clear to a SoGoEncryptWall API endpoint.
[12:09.280 --> 12:17.200]  And this request contains the AES key and initialization vector, which is used to encrypt other data in the request.
[12:17.880 --> 12:24.600]  And the data in the request is compressed, and then it's AES encrypted, and then after that, encoded.
[12:25.560 --> 12:31.460]  So as network eavesdroppers, we were able to intercept these HTTP POST requests and to alter them ourselves.
[12:31.460 --> 12:33.300]  And that's kind of our threat model.
[12:34.940 --> 12:38.780]  So we found that SoGo's EncryptWall was vulnerable to a padding Oracle attack.
[12:39.080 --> 12:44.820]  And the first one of these was published all the way back in 2002, which is a really long time ago.
[12:45.060 --> 12:46.560]  So it's not a new attack.
[12:48.500 --> 12:53.360]  And we found that they were vulnerable because of their use of AES CBC encryption.
[12:54.360 --> 13:02.320]  So AES, for those of you who don't know, is the Advanced Encryption Standard, which was developed in 2001 by the U.S.
[13:02.780 --> 13:07.200]  National Institute for Standards and Technology to replace DES when it became insecure.
[13:07.200 --> 13:20.580]  And CBC mode, it refers to cipher block chaining mode, which basically breaks the data into blocks of 16 bytes each for encryption and decryption.
[13:21.440 --> 13:29.160]  So AES is a form of symmetric encryption, which means that the same secret key is used both for encryption and decryption.
[13:29.160 --> 13:42.260]  And that means that it's really, really bad if someone gets your key because they can decrypt everything, which is why SoGo smartly encrypts their AES key with RSA, which is a form of asymmetric encryption.
[13:42.480 --> 13:44.500]  And so we couldn't get our hands on their key.
[13:44.800 --> 13:50.100]  But we didn't actually need their key to decrypt everything because of their use of CBC mode.
[13:51.700 --> 13:59.240]  So another operation, before I explain the padding oracle attack, you need to understand the XOR operation in order to understand our attack.
[14:00.380 --> 14:02.980]  It's really, really easy, as you can see in the chart there.
[14:03.120 --> 14:04.420]  You probably know what XOR is.
[14:05.420 --> 14:09.620]  But anyway, just all you need to know is it's super easy to reverse.
[14:09.900 --> 14:11.860]  The inverse operation is just itself.
[14:12.020 --> 14:16.580]  So if you have X XORed with Y and you have X, you can get back Y.
[14:16.940 --> 14:18.280]  And that's all you need to remember.
[14:19.800 --> 14:22.080]  So how do we do our padding oracle attack?
[14:22.300 --> 14:23.840]  Well, it all comes down to padding.
[14:24.420 --> 14:32.660]  If you don't know, padding is added to the end of the plaintext before encryption to make sure that every byte has exactly 16 bytes.
[14:33.220 --> 14:35.540]  Every block has exactly 16 bytes.
[14:35.880 --> 14:39.680]  And so if there's one extra space left, you add a one.
[14:39.880 --> 14:44.120]  If there's two little space left, you would get two twos, three, three threes, et cetera.
[14:44.120 --> 14:47.200]  This just means that the end of the plaintext is predictable.
[14:47.480 --> 14:48.500]  We know what it's going to be.
[14:49.640 --> 14:57.240]  So one of the first things that the server does after receiving and decrypting the encrypted data is to check to see if the padding is correct.
[14:57.860 --> 15:04.940]  We found that SoGo's server returned unique HTTP status codes when the padding was correct versus when it was incorrect.
[15:04.940 --> 15:06.940]  And this is our padding oracle.
[15:07.520 --> 15:16.660]  What this means, essentially, is that we can send it any ciphertext we want, and it will tell us if the padding is correct, which means we know the end of the plaintext.
[15:19.400 --> 15:30.400]  So the way that this works is we didn't have their AES key, but we didn't need it because we could change bytes of the ciphertext, and that would change bytes of the plaintext.
[15:31.240 --> 15:43.320]  As you can see in this diagram here, we started by changing the last byte of the second-to-last ciphertext block, the little red x, and then that alters the last byte of the plaintext.
[15:45.780 --> 15:48.260]  So we changed x there.
[15:48.520 --> 15:58.240]  We tried 256 times to see which x is the right one, and then when we got back correct padding, we knew what the last byte of the plaintext was.
[15:58.400 --> 15:58.880]  It was 1.
[15:59.300 --> 16:00.600]  1, 1 is correct padding.
[16:01.160 --> 16:05.320]  So we had x xor'd with y, and we had x.
[16:05.580 --> 16:11.080]  All we needed to do was just xor them together, and we get back y.
[16:11.080 --> 16:20.160]  And once we had y, we could xor with the original value of x, unchanged by us, and we get the last actual byte of the plaintext.
[16:20.780 --> 16:30.020]  So in this way, we managed to leak every byte of the plaintext one by one by trying all 256 options for each byte.
[16:31.640 --> 16:46.900]  So if you don't see how this could progress after the first one, it's just once we know how to make the last byte of the plaintext a 1, we can easily make it a 2, and then make the second-to-last byte of the plaintext a 2, correct padding again, and we just keep doing this.
[16:48.600 --> 16:59.800]  So that's how we decrypt everything, and it only becomes a little bit more difficult in the first block, because the first block we need to start changing bytes of the IV, or initialization vector.
[17:00.760 --> 17:04.740]  And that becomes trickier in some versions of the app, because they encrypt their IV.
[17:05.740 --> 17:07.680]  And that was true in the Windows version.
[17:08.480 --> 17:10.160]  So they encrypted their IV.
[17:10.380 --> 17:16.800]  We had no idea what it was, but we were able to recover it, because some of the plaintext they were sending was predictable.
[17:17.620 --> 17:20.820]  And so one of the things they sent was the URL.
[17:20.820 --> 17:22.440]  We knew what the URL was.
[17:22.700 --> 17:29.860]  And so we just sent our attack normally, except with an all zero initialization vector.
[17:30.300 --> 17:33.800]  And we got back the URL XORed with the IV.
[17:34.040 --> 17:37.360]  We knew the URL, reverse XOR, and we got the IV.
[17:37.360 --> 17:40.920]  And that's how we were able to decrypt everything in the Windows version.
[17:42.000 --> 17:46.720]  The Android version was even more complicated, because it had an extra step.
[17:47.680 --> 17:51.780]  Before encryption, they were XORing their plaintext with a key, K.
[17:52.420 --> 18:02.080]  And K was 32 bytes long, so that means that the first half of K was XORed with odd-numbered blocks, and the second half of K was XORed with even-numbered blocks.
[18:02.760 --> 18:12.540]  And this caused some problems for us, because we tried our normal attack, but all the odd-numbered blocks came out completely garbled, and the even-numbered blocks were completely in the clear.
[18:13.260 --> 18:27.160]  We were very confused about what was going on at first, but we eventually changed our code to make sure that even-numbered blocks were always in an even position, odd-numbered blocks always in an odd position, so they were XORed with the correct half of K.
[18:29.080 --> 18:42.820]  And it was also important in the Windows version to be able to get the first block, in case you were wondering why we wanted it so badly, because the data was compressed, and so we couldn't read any of it unless we had the first block, so we could decompress it.
[18:43.020 --> 18:44.560]  So, yeah, that's why.
[18:45.460 --> 19:03.720]  And an interesting side effect in the Android version was with all of our weird XORing that we did, we managed to recover the second half of the key K, K2, and they had been sending their AES key, our XORed with K, which meant that if we had K, we could retrieve their AES key.
[19:04.620 --> 19:09.220]  And so we had the second half of K, and we got the second half of their AES key back.
[19:09.360 --> 19:17.360]  I mentioned before it's very bad to let anyone ever know your AES key, because it's symmetric encryption, and so it's supposed to be a secret.
[19:19.400 --> 19:23.860]  But anyway, so we did get half of that as well as a strange XORing side effect.
[19:24.660 --> 19:33.820]  And one of the things that we decrypted in the Android version that they had been sending back to their server was a list of every single app installed on the Android device.
[19:34.540 --> 19:38.580]  I don't know why a keyboard app needs that, but oh well.
[19:40.080 --> 19:44.340]  So SoGo had some similarities to the other apps that we looked at.
[19:45.080 --> 19:54.360]  Unfortunately, we found out that SoGo's encrypt wall was also used by some other vendors, and also comes pre-installed on some phones.
[19:55.520 --> 19:58.040]  And so the same vulnerabilities were present there.
[19:58.880 --> 20:05.380]  The other apps that we looked at had also some similar vulnerabilities, in that they had static or predictable keys.
[20:05.380 --> 20:16.180]  They were using outdated cipher systems, even DES, and just generally rolling their own crypto and not using TLS.
[20:16.420 --> 20:21.040]  Except for Huawei, which did use TLS, even before disclosures.
[20:21.260 --> 20:24.340]  So that was why it was eight out of nine apps, not nine out of nine.
[20:26.540 --> 20:28.560]  So what exactly did we decrypt?
[20:29.140 --> 20:31.780]  Well, a lot of really boring stuff, to be honest.
[20:32.060 --> 20:34.260]  Except, that's weird.
[20:34.680 --> 20:37.820]  That looks like what we were typing when we were testing the app.
[20:38.520 --> 20:40.040]  So what's going on here?
[20:40.520 --> 20:49.860]  Well, all of these keyboard apps are sending user keystrokes to servers in China, and they are, for the most part, using pretty bad encryption to do it.
[20:50.040 --> 21:00.280]  And so a network eavesdropper, like we were pretending to be, we're pretending to be little evil eavesdroppers, could just read everything that users are typing.
[21:02.060 --> 21:05.080]  And so why are they doing this?
[21:05.240 --> 21:08.240]  Well, it's actually part of the functionality of these apps.
[21:08.540 --> 21:15.460]  They rely on a cloud-based predictive text feature in order to suggest which character a user may want to type next.
[21:16.000 --> 21:20.900]  And this is especially important when typing in Chinese, because there are just so many characters to choose from.
[21:21.900 --> 21:29.620]  And so it's actually a part of these apps, but they could be using better encryption if they are going to be sending user keystrokes.
[21:31.300 --> 21:39.540]  So we've made some vulnerability disclosures, a lot of them, actually, and it took a long time to communicate with all of these companies.
[21:39.540 --> 21:46.700]  But as you can see before our disclosures, many of these keyboard apps were vulnerable to our attacks.
[21:47.200 --> 21:50.380]  And afterwards, a lot fewer.
[21:50.980 --> 21:52.860]  So fixes were made.
[21:53.240 --> 21:55.560]  Many of them are using TLS now, which is good.
[21:56.960 --> 22:04.660]  Unfortunately, Honor and QQPinion are still not fixing the vulnerabilities that we identified.
[22:05.000 --> 22:08.780]  So that's not great, but mostly a win.
[22:09.600 --> 22:11.280]  So what does this mean for users?
[22:11.880 --> 22:22.160]  Well, if you're a user of any of these apps, please update your apps or your operating system if your phone is using one of these apps as a pre-installed keyboard.
[22:23.100 --> 22:31.640]  And then also, if you're using Honor or QQPinion, you should just switch keyboards immediately because we just told everyone how to hack you.
[22:32.040 --> 22:34.080]  Oh, please, please switch.
[22:35.220 --> 22:49.200]  And generally speaking, high-risk users should be aware that enabling cloud-based features in the apps means that the vendor and whoever they want to share their information with will still be able to read everything the users type on their devices.
[22:50.260 --> 22:58.220]  Also concerning to some users, maybe that these apps are operating under Chinese jurisdiction and subject to Chinese laws.
[22:58.800 --> 23:01.860]  So that could be concerning depending on who you are.
[23:02.640 --> 23:07.500]  So your keyboard might be compromised, but at least your browser is safe.
[23:07.740 --> 23:08.260]  Right, Jeff?
[23:11.600 --> 23:12.960]  We'll see about that.
[23:14.700 --> 23:19.520]  We'll be talking about privacy and security issues in bat browsers.
[23:20.140 --> 23:23.860]  You might be wondering, what is a bad browser?
[23:24.200 --> 23:25.960]  Let's begin with another short quiz.
[23:26.260 --> 23:28.040]  What's the most popular mobile web browser?
[23:29.080 --> 23:30.280]  Probably can guess.
[23:30.480 --> 23:30.980]  Yes, right.
[23:31.280 --> 23:31.900]  Google Chrome.
[23:32.700 --> 23:34.960]  What's the second most popular mobile web browser?
[23:35.220 --> 23:46.300]  And note the tiny text there which says in 2016 when we originally began this research because this browser is no longer as popular possibly due to this research.
[23:48.180 --> 23:49.400]  It's this one.
[23:49.700 --> 23:54.320]  And if you don't recognize it, this is UC browser.
[23:54.740 --> 24:01.300]  It's very popular in Asia, not just in China, but in other parts of Asia at large.
[24:03.380 --> 24:10.240]  And to get back to the original question, Bat refers to the three largest tech companies in China.
[24:10.840 --> 24:13.180]  Baidu, which develops Baidu browser.
[24:14.080 --> 24:16.720]  Alibaba, which owns the company that develops UC browser.
[24:17.560 --> 24:19.400]  And Tencent, which develops QQ browser.
[24:21.200 --> 24:24.060]  What motivated us to look at these browsers?
[24:24.420 --> 24:33.720]  Well, we knew thanks to Edward Snowden and leaked slides that these browsers under active exploitation by the NSA and the other Five Eyes.
[24:34.860 --> 24:36.260]  I'll have more on this later.
[24:38.120 --> 24:39.920]  So these are our high-level findings.
[24:39.920 --> 24:43.540]  We reverse-engineered the Android and Windows versions of these browsers.
[24:43.900 --> 24:53.300]  We found that all of them use what we call easily decryptable cryptography or sometimes no cryptography at all to transmit sensitive data.
[24:53.660 --> 25:00.120]  We also found that most of them have a lack of cryptography protecting the way that they update themselves.
[25:00.120 --> 25:07.040]  So they will download an update and install it without checking signatures, for instance.
[25:08.880 --> 25:13.280]  So I mentioned easily decryptable cryptography.
[25:13.640 --> 25:15.120]  What do I mean by that?
[25:15.520 --> 25:23.220]  Well, that's something that's easily decryptable by anyone eavesdropping on the traffic who has reverse-engineered the software.
[25:23.220 --> 25:38.360]  So as an example of this, this would be like a naive home-rolled cryptography algorithm, but also just any symmetric crypto algorithm where the key is hard-coded, as well as asymmetric cryptography that has otherwise flaws.
[25:38.680 --> 25:44.000]  But why is a hard-coded symmetric key so devastatingly awful?
[25:44.600 --> 25:46.820]  Well, let's have a reminder.
[25:46.820 --> 25:55.880]  Under, you can see the figure on the top, Semantic Tree Crypto, use the same key to encrypt as you use to decrypt.
[25:56.600 --> 26:14.140]  So if you're hard-coding your encryption key into your app, and I reverse-engineer your app, and I find your key, that means that I can decrypt, as a network eavesdropper, everything that you're encrypting with that key that you're transmitting over the network.
[26:16.820 --> 26:21.740]  Here are the different kinds of data that we found these browsers phoning home.
[26:22.960 --> 26:27.080]  Personally identifiable information, for instance, hardware serial numbers.
[26:28.020 --> 26:40.060]  If you're using a mobile device, this is less relevant these days due to updates with those operating systems, but this is still a very realistic concern if you're using a desktop operating system.
[26:40.280 --> 26:51.400]  We found location information, such as your geolocation coordinates, which Wi-Fi network you're connected to, lists of Wi-Fi networks that are in range.
[26:51.800 --> 27:03.560]  And since these are browsers, they also phoned home information about your activities, such as what are you searching for, the URL of every page that you visit, the title of every page that you visit.
[27:03.740 --> 27:08.140]  And remember, they're phoning this home with really crappy cryptography.
[27:10.400 --> 27:15.140]  So just to walk you through an example, here's a transmission from UC Browser encrypted.
[27:15.700 --> 27:19.140]  This is something that, for instance, you could dump using Wireshark.
[27:20.220 --> 27:21.760]  You know, how can we decrypt this?
[27:22.240 --> 27:24.580]  Well, we reverse engineer the software.
[27:24.620 --> 27:28.220]  We see, uh-oh, there's no asymmetric cryptography protecting this at all.
[27:28.460 --> 27:35.140]  Turns out they're using some home-rolled XOR based algorithm that they have come up with on their own.
[27:35.400 --> 27:38.380]  We discover something resembling a key that's hard-coded.
[27:38.640 --> 27:41.160]  And so we write a Python script to decrypt it.
[27:41.620 --> 27:48.380]  And so we can turn something like this into something like this, which has information about my CPU.
[27:49.000 --> 27:54.460]  It has the serial number of my hard drive, as well as the version of the operating system I'm running.
[27:55.000 --> 27:56.280]  That's another example.
[27:56.960 --> 27:58.860]  You can see it sending the URL.
[27:58.860 --> 28:02.180]  It's phoning that home of every website that I visit.
[28:04.400 --> 28:07.320]  So just to go through the browsers and what we all found on them.
[28:07.920 --> 28:14.620]  By your browser, we found all sorts of information being phoned home using hard-coded keys.
[28:15.020 --> 28:17.820]  One was a hard-coded RC4 key, hard-coded AES.
[28:18.480 --> 28:21.080]  They were encrypting things with XOR masks.
[28:21.840 --> 28:37.920]  One of the more interesting things that we found that they were using was, you wouldn't normally consider base64 encoding to be encryption, but they were doing something weird where they were using a non-standard alphabet where they just sort of shuffled all the letters around and then base64 encoded using that.
[28:39.940 --> 28:41.920]  So I guess that's technically cryptography.
[28:43.920 --> 28:50.640]  They also used a modified version of the tiny encryption algorithm with a hard-coded key, and so on.
[28:52.620 --> 28:56.660]  UCBrowser, like we saw earlier, the hard-coded XOR based key.
[28:57.020 --> 28:58.800]  There are a few other examples of that.
[28:59.020 --> 29:01.900]  A hard-coded XR mask, hard-coded AES key.
[29:04.200 --> 29:13.840]  QQBrowser was interesting because they actually had all of those same sorts of problems, but for a lot of the info that they were phoning home, they did attempt to use asymmetric cryptography.
[29:14.260 --> 29:18.880]  So here's an example of one of the RSA public keys that we found.
[29:20.260 --> 29:27.220]  And if you remember with RSA, if you can factor this number, then we can derive the RSA private key.
[29:27.500 --> 29:32.500]  That can be used to decrypt anything that this RSA public key is encrypting.
[29:33.140 --> 29:35.260]  Well, what's wrong with this public key?
[29:36.640 --> 29:38.840]  Well, we were able to decrypt him.
[29:39.100 --> 29:40.500]  Or sorry, we were able to factor him.
[29:40.900 --> 29:44.840]  And to do so, we built our own quantum computer.
[29:47.040 --> 29:49.200]  No, I'm kidding, of course.
[29:49.680 --> 29:53.340]  We copied and pasted it into Wolfram Alcar.
[29:58.340 --> 30:03.460]  And in less than a second, we were able to factor that number.
[30:03.460 --> 30:06.040]  And so, well, we could derive the private key.
[30:07.820 --> 30:09.320]  A host of other mistakes.
[30:09.620 --> 30:14.960]  So here's how they were so-called randomly generating some of their symmetric keys.
[30:15.620 --> 30:19.240]  So they were trying to generate a 16-byte key here.
[30:19.480 --> 30:26.320]  Though the way they thought to do that was, let's just concatenate two eight-digit numbers together.
[30:27.700 --> 30:29.880]  You know, there's two problems with this.
[30:29.980 --> 30:34.940]  One, just by doing that, you're radically reducing the entropy of that key.
[30:35.280 --> 30:38.420]  But you might have noticed sort of another weird thing about this, too.
[30:38.840 --> 30:45.280]  Where the maximum range that they're generating these numbers from is eight, nine, nine, nine, nine, instead of nine, nine, nine, nine, nine.
[30:46.920 --> 30:47.640]  I can't...
[30:47.640 --> 30:49.460]  I don't know what to say about that.
[30:53.920 --> 30:58.460]  Here's another one where they're deriving a key from the current time.
[30:59.380 --> 31:00.860]  What's the problem with this?
[31:01.160 --> 31:06.040]  Well, anyone who knows what time it is knows how to decrypt through traffic.
[31:09.880 --> 31:15.880]  One of the more subtle attacks we did was on their use of what's called textbook RSA.
[31:15.880 --> 31:19.240]  So this is RSA without the use of any kind of padding.
[31:19.520 --> 31:30.740]  And the way that this opens up use of RSA to attacks is because you can do all sorts of math on the encrypted payload that you wouldn't normally be able to do.
[31:31.600 --> 31:40.400]  To make a long story short, we were able to attack this cryptography doing a similar attack to the one that Zoe was describing earlier.
[31:40.940 --> 31:47.720]  In this one, we actually learn things about the encrypted key one bit at a time instead of one byte.
[31:48.080 --> 31:52.400]  But, you know, since he is 128 bits, it doesn't take that long.
[31:55.450 --> 32:04.790]  With Baidu Browser, we actually found that a lot of what was being transmitted wasn't due to the browser proper but due to something called the Baidu SDK.
[32:06.290 --> 32:12.610]  We searched for a whole bunch of other apps in the Google Play Store and we found its presence in a whole bunch of them.
[32:12.790 --> 32:17.730]  The most popular one being the ES File Manager.
[32:17.770 --> 32:25.770]  I think at the time, it was the most popular file manager for Android with between 100 million and 500 million installs.
[32:30.310 --> 32:39.210]  And just as I was alluding earlier, these browsers did not use proper cryptography when they're downloading and installing updates.
[32:39.210 --> 32:42.130]  This means that they're vulnerable to remote code execution.
[32:42.990 --> 32:54.270]  The way that these vulnerabilities are introduced is a failure to check digital signatures or a failure... or maybe they check the digital signature but they don't check that the version number is higher.
[32:54.770 --> 32:58.930]  Or maybe they check that but they don't actually check that it's the same app.
[32:59.610 --> 33:02.730]  And so, you know, this can introduce all sorts of problems.
[33:02.730 --> 33:15.990]  So you can either update to arbitrary software or you could downgrade or you could sidegrade to a different product that they have, one that has additional vulnerabilities in.
[33:18.710 --> 33:22.950]  So we disclosed all these vulnerabilities to the vendors.
[33:23.710 --> 33:25.190]  Most were fixed.
[33:25.590 --> 33:26.790]  Some were not.
[33:27.550 --> 33:32.230]  And new ones of the same variety have since been reintroduced.
[33:34.290 --> 33:35.850]  Why is this so important?
[33:35.850 --> 33:41.290]  Well, as I alluded to before, we know that these browsers...
[33:41.290 --> 33:51.210]  We know that at least UC Browser and presumably the others are under active exploitation by the NSA and the other Five Eyes just because they've told us so.
[33:51.210 --> 33:53.010]  We know this from the leaked slides.
[33:53.610 --> 34:03.110]  We know that they're exploiting the crummy cryptography that they use to record all sorts of sensitive data that's being transmitted.
[34:04.770 --> 34:07.250]  Here's an example of what's called an XKeyScore plugin.
[34:08.210 --> 34:15.390]  They wrote one of these for UC Browser and that lets them track all stuff that it's sending from all over the world.
[34:18.050 --> 34:28.610]  Inside of these leaked slides, they also mention a UC Browser vulnerability that allows them to install arbitrary software on people's machines.
[34:28.850 --> 34:36.350]  We think this could be the problems with this auto-updating process that we discovered in UC Browser.
[34:36.650 --> 34:43.710]  It could also be a different vulnerability that they found too, but we suspect it could be the one that we found just because of how easy we found it.
[34:46.070 --> 34:47.590]  So how did this happen?
[34:48.250 --> 34:53.790]  Aren't browsers supposed to be the most secure software that we have on our machines?
[34:54.110 --> 34:55.810]  So why are these so awful?
[34:56.610 --> 35:01.250]  Well, the first thing you might be thinking, well, could this be a deliberate backdoor?
[35:01.810 --> 35:05.950]  The Chinese government put it there, but that's just not the case.
[35:06.630 --> 35:08.910]  These are really awful backdoors.
[35:09.250 --> 35:16.150]  If you want to put a backdoor in something, you want to be the only one who can go through that door, whereas with this, everyone can go through.
[35:16.510 --> 35:19.570]  And that's not desirable at all.
[35:20.390 --> 35:26.770]  The Chinese government has been working to try to improve the security of the encryption of their domestic software.
[35:27.010 --> 35:33.330]  And plus, since all this data is being sent to servers in China anyways, they have other ways of getting this data.
[35:33.330 --> 35:36.690]  They could use warrants or other sorts of lawful access requests.
[35:38.350 --> 35:42.450]  So what we think is probably more likely are market factors.
[35:45.730 --> 35:51.990]  Software development is highly competitive, perhaps even more so in China, where there would be extremely tight deadlines.
[35:52.690 --> 36:02.250]  When it comes to ad tech, there's often a philosophy of, well, let's just collect everything and then try to, you know, use it to target people with ads later.
[36:04.450 --> 36:07.570]  So, you know, design it as quickly as possible.
[36:07.810 --> 36:09.570]  And then maybe security is an afterthought.
[36:11.030 --> 36:12.850]  There's also political factors as well.
[36:13.070 --> 36:14.390]  So Google is blocked in China.
[36:14.610 --> 36:17.410]  That means folks can't access the Google Play Store.
[36:17.950 --> 36:21.810]  Though these apps oftentimes aren't even submitted to the Google Play Store.
[36:22.650 --> 36:34.270]  The Google Play Store does provide an additional layer of review and scrutiny to these apps, which makes it possible that, you know, some of these problems could have been prevented through some sort of app review.
[36:35.810 --> 36:39.350]  There may also just be some skepticism of Western cryptography.
[36:40.090 --> 36:42.470]  And some of this, rightfully so.
[36:43.090 --> 36:49.090]  For instance, the elliptic curve, which many believe might have an NSA backdoor in it.
[36:49.090 --> 36:53.370]  It sort of invites that sort of skepticism.
[36:53.930 --> 37:02.810]  And some of that skepticism might also sort of be applied to TLS and other sorts of protocols that they should be.
[37:04.750 --> 37:06.030]  So some of the takeaways.
[37:07.030 --> 37:10.790]  Well, we have to pay more attention to apps from understudy ecosystems.
[37:11.750 --> 37:14.030]  Just doing a cost-benefit analysis.
[37:14.410 --> 37:17.050]  These ecosystems have huge user bases.
[37:17.430 --> 37:22.650]  The apps can have major vulnerabilities that are often easy to find.
[37:22.890 --> 37:25.690]  And so this can be very high-impact research.
[37:26.830 --> 37:32.870]  Finding vulnerabilities in popular North American browsers or other North American software is becoming increasingly difficult.
[37:32.870 --> 37:39.850]  So, you know, why not study something where it's easier and where the vulnerabilities affect more people?
[37:41.950 --> 37:47.310]  Any researcher that even looked at this traffic in Wireshark would know that there's a problem.
[37:47.810 --> 37:55.050]  But the good news is that, you know, how to use Wireshark, you can get going analyzing understudied software.
[37:56.370 --> 38:00.950]  And so, please join us in studying software from these understudied equations.
[38:01.490 --> 38:02.230]  Thank you.
[38:12.700 --> 38:21.460]  So, there's another kind of software that's in a perfect position for poor encryption, and that is antivirus software.
[38:21.840 --> 38:32.260]  I've done a little looking at Chihu, which has more than a 90% market share in China for AV.
[38:32.260 --> 38:39.000]  And it's constantly talking encrypted in a peer-to-peer network.
[38:39.240 --> 38:44.160]  Even when there's nothing happening on an idle machine, it's talking.
[38:44.160 --> 38:52.280]  I have no idea if it's updating its AV signature files, if it's leaking stuff from the client machines.
[38:52.580 --> 38:54.480]  What the hell is going on?
[38:54.600 --> 39:02.620]  Now, I happen to have some history with the company because it's a spin-off of Yahoo, and I worked at Yahoo at the time.
[39:02.720 --> 39:07.020]  And I don't trust them at all, based on personal experience.
[39:07.560 --> 39:11.280]  So, I wonder if you've had any time...
[39:11.280 --> 39:17.820]  And by the way, of course, everybody understands that antivirus software needs access to every file on the machine.
[39:17.820 --> 39:20.180]  It needs access to your browser activity.
[39:20.500 --> 39:28.260]  And if it sees something suspicious, it might upload it to, you know, Mission Central for further checkout.
[39:28.600 --> 39:32.680]  So, that's considered ordinary behavior.
[39:33.280 --> 39:41.540]  So, and of course, now Kaspersky is banned worldwide because he's untrusted even though nobody's been able to prove anything about him.
[39:41.540 --> 39:45.800]  So, I wonder if you've had any time to look at the Chinese antivirus market as well.
[39:48.560 --> 39:50.680]  I don't think that we have, have we?
[39:50.780 --> 39:51.320]  Has anyone here?
[39:51.500 --> 40:07.620]  Not specifically the antivirus markets, but a lot of software that's pre-installed on phones that are intended for the Chinese market are sending a lot of data home using proprietary encryption.
[40:07.620 --> 40:12.720]  So, this is something that we are monitoring, but there are just so many.
[40:13.080 --> 40:22.940]  Like, if you remember that slide, it's like every single, you know, top Chinese app is using some SDK that it's using some amount of proprietary encryption.
[40:23.080 --> 40:24.980]  They're all different from each other.
[40:25.160 --> 40:27.880]  They're probably all broken in different ways.
[40:28.120 --> 40:35.960]  So, you know, if you see something, we do encourage you to study it because, you know, we can't study everything.
[40:37.560 --> 40:40.880]  I really do like the idea though, so it will be on my to-do list.
[40:41.640 --> 40:42.220]  I bet.
[40:44.400 --> 40:46.980]  Two questions, and I hope that they're both broken up.
[40:47.240 --> 40:55.200]  The first one is, did you notice any difference between the Chinese internal-facing Internet and the outside-the-world-facing Internet?
[40:55.200 --> 40:58.340]  Which I understand are two very ecosystems a lot of the time.
[40:58.800 --> 41:09.120]  And the second question that I had is, were there any things that you noticed systemically that Chinese apps and whatnot actually did very well?
[41:09.200 --> 41:12.560]  Or was it just across-the-board sort of amateur hour mistakes?
[41:13.400 --> 41:13.660]  Thank you.
[41:14.300 --> 41:27.020]  Yeah, so these apps behave the same in terms of, like, cryptography, whether you're using them outside of the Great Firewall or inside of the Great Firewall, which I believe addresses your first question.
[41:27.800 --> 41:29.720]  The second one is a little bit more difficult.
[41:29.780 --> 41:31.360]  So what were these apps doing right?
[41:32.980 --> 41:38.560]  I actually saw a lot of quick usage in a lot of the newer apps.
[41:38.980 --> 41:56.880]  Another hypothesis we have is that the apps that got popular earlier, so for instance, WeChat, I don't know, even UC Browser, a lot of these apps became popular in the early 2010s, before TLS was, like, a universal, like, standard.
[41:57.420 --> 42:11.140]  And they probably maybe had a need for encryption before TLS was regarded as a universal standard, and so they started just writing their own encryption, and inertia has prevented them from switching.
[42:11.140 --> 42:21.100]  So I will say, apps that are developed post-2015, like, you know, I use Chinese apps, I play a lot of Genshin Impact, seems fine.
[42:21.620 --> 42:25.920]  Like, this made me really paranoid about, like, all my traffic.
[42:30.800 --> 42:39.200]  Kind of half-answered my question with that, but is there, what's the environment around, like, certificate authorities in China, and there's, like, a mistrust around it?
[42:39.220 --> 42:44.940]  I was watching the talk, and I was just thinking, like, are they avoiding TLS because they don't trust the authorities?
[42:47.440 --> 42:50.180]  Yeah, that's actually one of the hypotheses we have as well.
[42:50.860 --> 43:02.060]  There are now certificate authorities in China that are trusted by the CA browser, which is, like, a forum, which is a democratic alliance of a bunch of...
[43:02.060 --> 43:03.380]  Okay, maybe not democratic.
[43:04.160 --> 43:04.960]  I don't know.
[43:04.960 --> 43:11.680]  It's a group of browsers and CAs that decide a bunch of roles and inclusion roles for all of the operating system lists and stuff.
[43:13.000 --> 43:23.300]  Yeah, I don't know that much more about that, but I do suspect that mistrust in the CA ecosystem also contributed to the lack of adoption of TLS in, say, 2011.
[43:31.420 --> 43:34.780]  Actually, the reason is for the lack of not using TLS.
[43:34.960 --> 43:37.540]  I mean, we've had SSL since 1995.
[43:39.760 --> 43:45.100]  And actually, it had a padding attack, very similar to the one that you exploited there in 97.
[43:46.120 --> 43:52.400]  The big problem was that we never really thought about device security for the WebPKI.
[43:52.660 --> 43:56.740]  The WebPKI is just not designed to do that, and I'm one of the authors, so sorry.
[43:58.120 --> 44:05.900]  I was going to ask about devices, because, you know, people are probably looking, listening to this and thinking, oh, well, this is all Chinese stuff.
[44:06.120 --> 44:15.960]  It's got your television, your toaster, your coffee pot, you know, all this stuff that people buy like nanny cams.
[44:16.440 --> 44:18.220]  Have you looked at any of that stuff?
[44:18.420 --> 44:21.460]  Because I'm pretty sure that it's the same sort of horror show.
[44:25.710 --> 44:34.490]  I haven't, or we haven't looked at IoT or sort of devices, but I think that is an area right for research.
[44:34.670 --> 44:36.170]  I would encourage you to look there.
[44:36.230 --> 44:38.430]  Yeah, or if anyone else wants to do it.
[44:40.250 --> 44:42.590]  Our to-do list is getting longer and longer.
[44:45.650 --> 45:04.150]  So is it possible that the reason why some of these apps are reluctant to use HTTPS is that corporate gateways that intercept HTTPS, and they do exist here too, including my previous employer, I imagine they're more prevalent in China.
[45:04.390 --> 45:11.930]  And so one way to not get blocked or get met in the middle by them is you use HTTP, and then you put the encrypted traffic inside.
[45:11.930 --> 45:15.890]  And so, you know, traffic gets logged by the gateway, but it's still encrypted.
[45:17.510 --> 45:26.210]  So this happens, of course, to devices where the employer can install a TLS certificate, a CA on the device.
[45:28.070 --> 45:29.670]  That's an interesting hypothesis.
[45:29.870 --> 45:34.730]  Do you think that their motivation might be to actually try to...
[45:34.730 --> 45:39.370]  Their original motivation might have been to try to make their data less vulnerable to surveillance?
[45:40.330 --> 45:48.090]  Yeah, it seems like a, you know, ill-guided probably, but like a sufficient motivation, because you get blocked or a man in the middle.
[45:48.410 --> 45:54.590]  And I have used devices where every website, including Google.com, was my employer.
[45:55.370 --> 46:08.990]  So, yeah, one way QQ or, you know, Baidu can work it around is by having their own CA system with their own encryption keys.
[46:10.290 --> 46:15.490]  Yeah, I mean, it's hard to speculate about what they were thinking, I guess.
[46:15.490 --> 46:26.890]  But, you know, certainly a much better way of solving that problem would be something like certificate penning, which would have solved it.
[46:28.250 --> 46:28.810]  Hi.
[46:28.810 --> 46:30.790]  So I was wondering...
[46:30.790 --> 46:40.430]  I was generally really curious about when you went back and looked at the remediation efforts, when these companies actually said that they fixed the bugs that you guys found.
[46:40.430 --> 46:44.470]  I was curious, what did those fixes look like?
[46:44.470 --> 46:53.070]  Were they actually redesigning their entire sort of encryption stack to use like TLS and certificate authorities?
[46:53.070 --> 46:58.850]  Or were they patching individual vulnerabilities found at like the protocol layer of what they implemented?
[47:00.390 --> 47:05.470]  You know, best case scenario, they switched to TLS, and that's generally the case.
[47:05.590 --> 47:08.450]  It was certainly the case for the keyboard apps that we looked at.
[47:09.390 --> 47:11.090]  Well, except Baidu, right?
[47:11.990 --> 47:17.090]  Yeah, it was generally the case for the keyboard apps with the exception of Baidu.
[47:17.810 --> 47:35.270]  And with the browsers, this might not be true as of 2024, but I believe that Tencent is still using some variation of that RSA algorithm that I was talking about in the slides.
[47:35.270 --> 47:37.370]  They've made improvements to it.
[47:37.870 --> 47:40.650]  The key is larger now, et cetera, et cetera.
[47:40.930 --> 47:46.110]  But I believe they're still trying to, you know, home roll their cryptos, so...
[47:47.450 --> 47:53.870]  Yeah, and I think our... I mean, we published our correspondence with Baidu, which I thought was quite interesting.
[47:54.350 --> 47:56.870]  We said, you know, this is really bad.
[47:57.690 --> 48:05.930]  They... but then they upgraded them all to another proprietary protocol that used asymmetric encryption, like, a little bit better, but it was still not CPA secure.
[48:06.190 --> 48:07.730]  Like, they were... it was deterministic.
[48:07.730 --> 48:09.390]  They were reusing the IV and the key.
[48:09.490 --> 48:11.530]  A bunch of, like, problems that we listed.
[48:11.850 --> 48:14.710]  And then, you know, and then they were like...
[48:14.710 --> 48:15.510]  Okay.
[48:16.630 --> 48:18.370]  I think that... like, I don't know...
[48:18.370 --> 48:19.770]  And then they didn't do anything.
[48:20.890 --> 48:21.370]  So...
[48:21.890 --> 48:29.250]  Just really quickly, if you guys are interested in what we were talking about, you can find reports about these things on the Citizen Lab website.
[48:29.710 --> 48:33.410]  And Mona will probably have a report upcoming about the WeChat stuff as well.
[48:33.590 --> 48:34.690]  So check it out.
[48:34.870 --> 48:37.130]  If you've heard of the Citizen Lab, that's where we're at.
[48:39.390 --> 48:40.050]  All right.