Readit News> Seabed 2030 is a long-term mapping project attempting to fully chart the seafloor and reveal all features 100 meters or larger by 2030.
There is an area of interest, "Area 3: Indian Ocean: Ninetyeast Ridge" around 30S 87E, which specifically mentions MH370:
https://seabed2030.org/wp-content/uploads/2023/06/AtlanticIn...
Though that is quite a bit (~830 km / ~1250 km from the center of the square around 30S 87E) off to the (north)west of the most recent search proposal from mh370search.com:
https://www.mh370search.com/2024/03/16/mh370-a-new-hope/
edit: Got the distance wrong. Corrected.
If a TLS handshake is aborted partway through, Wireshark will label it “TLSv1”. It actually retroactively labels the 1.0 TLS packets as 1.3 after a successful TLS 1.3 handshake finishes.
This makes sense because a TLSv1.3 handshake actually starts as 1.0 and then upgrades to 1.3 only with IIRC the Server Hello response to the ClientHello.
The following links document this behavior, in case you or your organization’s security team is nervous TLSv1 is actually being used:
https://superuser.com/a/1618420
https://ask.wireshark.org/question/24276/how-does-wireshark-...
edit: Ah, that GitLab link lead me to https://gitlab.com/wireshark/wireshark/-/issues/19515 which is a recent discussion around this topic and https://gitlab.com/wireshark/wireshark/-/merge_requests/1377... already dealt with it :)
Second, I see that whatever client he's using is specifying a very old TLS 1.0. If its not MTU (which others have mentioned), then my guess would be a firewall with a policy specifying a minimum TLS version, and dropping this connection on the floor.
Deleted Comment
Edit: just realized it must have been that the initramfs image is not updated with the manually updated firmware in /lib/firmware.
Edit2: Updated the initramfs and even if the benchmark.sh fails, ./zenbleed -v2 still picks out and prints strings which doesn't happen with the wrmsr solution.
The fixed Renoir microcode should have revision >= 0x0860010b as per the kernel: https://github.com/torvalds/linux/commit/522b1d69219d8f08317...
Deleted Comment
Deleted Comment
The way around this, as a developer, is URL-safe-base64 encode the value. Then you have a bytes primitive & you can use whatever inner representation your heart desires. But the article does also note that you're not 100% in control, either. (Nor should you be, it is a user agent, after all.)
I do wish more UAs opted for "obey the standard" over "bytes and an prayer on the wire". Those 400 responses in the screenshots … they're a conforming response. This would have been better if headers had been either UTF-8 from the start (but there are causality problems with that) or ASCII and then permitted to be UTF-8 later (but that could still cause issues since you're making values that were illegal, legal).
And make sure to specify what exactly you mean by that. base64url-encoding is incompatible with base64+urlencoding in ~3% of cases, which is easily missed during development, but will surely happen in production.