Tom Murphy VII has recently published the paper No one can force me to have a secure website!!! in the SIGBOVIK conference (direct link, conference proceedings to be published here) and accompanying YouTube video and live presentation at SIGBOVIK detailing an implementation of a deliberately insecure TLS implementation deployed to their website called HTTPV (HyperText Transport Protocol Vulnerable). They say they used multiple prime factors (more than two) to generate a RSA modulus, making it easy to factor the key on a reasonable budget. They state that the key has been signed with a Let’s Encrypt certificate.
I believe this is a willful violation of section 3.1, point 6 in the Let’s Encrypt Subscriber Agreement
By requesting, accepting, or using a Let’s Encrypt Certificate, You warrant to ISRG and the public-at-large that […] You have taken all appropriate, reasonable, and necessary steps to assure control of, secure, properly protect, and keep secret and confidential the Private Keys corresponding to the Public Keys in Your Certificates (and any associated activation data or device, e.g. password or token).
This represents a direct danger to visitors of the website and Murphy themselves. For example, they describe using their credit card number as a ServerHello.Random value, which could be stolen this way. Users could also accidentally leak data if they accidentally connect to the affected website. Hence, the certificates in question should surely be revoked.
The website is vulnerable to Bleichenbacher's attack. If you want to revoke the website certificate, you could do it yourself by revoking the certificate's key.
Edit: It appears to have countermeasures against this attack but maybe not ROBOT.
I think I should clarify that this post was made mostly as a joke; I personally do not believe this represents an actual danger in any realistic scenario.
It has been brought to my attention that the text of the post doesn’t make this intention very clear.
While the video does state this, the veracity of the statement is not incontrovertible. The CA has not yet been "made aware of a demonstrated or proven method that can easily compute the Subscriber's Private Key" (BRs, Section 4.9.1.1, Paragraph 4). If someone were to provide such demonstration or proof (via our official problem-reporting channels), we would then be required to revoke.
The video shows that the credit card number used as such expired in 2025, although again the veracity of that statement is not incontrovertible.
Appreciated, but note that while this may be a joking matter to you, our compliance posture and continued trust depend directly on how we respond to reports like this. Please refrain from making them in jest, as they cause real work on our side.
Running a "real" (non-honeypot) webserver with a full Heartbleed vulnerability in 2026 is wild...
Just tested it, yup that works. This is "real" server memory alright (the code caps us to 16KiB sadly [Tom 7 Misc / SVN / [r7010] /trunk/httpv/httpv.cc, line 1405):
Yeah it's kinda fake as the buffer is pre-configured once we go out of bounds....
PS: Dropped my own random padding to see if we get anything more from that server, but no it's only that short string and then only zeros:
Are you certain? Line 1411-1414 of httpv.cc just fills the response with a preconfigured value.
Yes you're right, I hadn't read far enough into the code. I was testing this first and the values were non-repeatable, but that's because it actually properly echoes the initial bytes before appending the "fake" buffer (it's been a while since I last saw a TLS server with heartbeat extension support).
Thanks for the clarification, it was unclear to me to what degree this forum was serious complaints and how much it was a more informal community support forum.
Totally understandable. This forum is largely just community support, and some amount of joking around is delightful and encouraged -- it fosters community. Unfortunately the standard for revocation is when the CA is "made aware", and different folks have had different interpretations of what exactly that means, so we try to be careful with regards to that specifically.
