The setting, simplified: you send RSA(aes-key), AES(key, message). The server replies if the AES key it recovers from the RSA message successfully decrypts the AES ciphertext; the server is an oracle for whether the message is valid.
The attack is stupid simple: the attacker shifts 127 of the AES key bits off of the RSA message --- the attacker can do this, because RSA is homomorphic with respect to multiplication and thus malleable --- and then sends the bit-shifted RSA message along with an AES ciphertext encrypted with the 0b1000...0 AES key. If that elicits a server response, the attacker knows the bottom bit of the real AES key is 1. The attacker repeats with a 126 bit shift, then the math teachers and so on until everyone is eaten.
However, papers like this are extremely useful, as they show new ways to exploit this theoretical vulnerability in a real-world case study.
where Cb = C (2^(be) mod(n)) (mod n)
I assume we are calculating Cb by encrypting the bit-shift and then applying it to C (which is already encrypted). Why do we need that last modulus at the end?
>Through reverse engineering, we have documented
the encryption protocols used by QQ Browser to protect
the trove of sensitive information each client uploads to
QQ Browser’s servers (this is summarized in Section 2).
This sensitive information includes International Mobile
Equipment Identifier (IMEI) numbers, web pages vis-
ited, locational data, and many other kinds of private data
about a QQ Browser user. The possibility that Tencent
shares this information with state actors is explored in
existing reports , and QQ Browser’s data collection
mirrors competing browsers such as UC Browser 
and Baidu Browser .
Review process: https://wiki.mozilla.org/Firefox/Data_Collection and not only is the source available, you can inspect opt-in metrics in about:telemetry, and see aggregated metrics at telemetry.mozilla.org (no other vendor will share that with you)
> There ought to be a full transparency report on every browser...
Yes, but not all browser vendors care about your privacy.
So if privacy matters to you use Firefox :)
And I do use Firefox.
But they really should not have done that, even if in the end the actual harm done was nil it broke trust.
There is also this:
I actually take exception to your classifying my comment as FUD, I'm in nobody's pocket (pun intended) and the worst you could accuse me of is being wrong. That said I was happy to trust the Mozilla of the past a lot more than I'm willing to trust the Mozilla of the present. Their forced upgrade strategy breaking my workflow and the Mr. Robot episode on top of that did little to assure me that they still have my best interest in mind. The thing that keeps me from switching is that I'm pretty sure all the competition is much worse.
jaquesm is merely pointing out that "use Firefox" needs a disclaimer today, whereas in the past one could simply use Firefox out of the box.
But that's beside the point, jaquesm said he expected browser vendors to clearly state what information they collect, I think Mozilla does a pretty comprehensive job at that:
And equating all data collection with spyware does NOT help win the battle. We're all on the same side here, but blowing things out of proportions doesn't serve the goal. It makes people give up.
It's fair to disagree with some decisions, and you don't have to opt-in for telemetry, but calling it spyware is unfair. It fair for you to say that you don't think it's necessary for your browser to collect performance metrics, and it's fair for you to not opt-in.
Equating things you dislike or find unnecessary with spyware is very dangerous. It gives other people the idea that browser choice doesn't matter. That privacy is impossible.
Note: we see extremism and exaggeration like this many places (politics included), and we have to be the ones holding each other to be reasonable. Otherwise, the opposition will frame us all as fanatics :)
In fact I believe sslstrip can do all this for you. Including giving it a CA to generate certificates out of.
I assume Tencent's QQ Browser validates certificates properly, but combined with a horrible RSA implementation that's not worth anything. It's actually a more clever (less visible) way of pretending to establish secure/authenticated connections.
I feel it would be better to simply define RSA encryption as follows:
First, generate key pairs, exchange public keys, etc.
Then, apply a padding function to your plaintext. The definition of a padding function can be found in section <Section number>.
Then compute c = m^e (mod n).
Send the resulting ciphertext c to the other party.
For a practitioner's book, it's probably worthwhile to introduce the doom principle early on, and refer to it later in contexts like this one where taking it into account would save your ass. But it's no replacement for reading the entire section about the thing you are implementing.
 https://web.archive.org/web/20170930085357/https://moxie.org... - unfortunately, the link on moxie.org is currently broken.
As a reference point, on Ti89 it takes about a minute to factorize 120bit RSA-style product of two primes, extrapolating from that you probably can break 128bit RSA on that without changing batteries.