14 ms·

See this page fetch itself, byte by byte, over TLS

1341 points by gmac 3y ago

demarq 3y ago
This is a really beautiful way to see something we take for granted all the time. The fact that computers can do all this in the blink of an eye (sans network speed) is just mind blowing.
- IanCal 3y ago
  One kinda related thing I find constantly amazing is that your processor running at x GHz will have had several more ticks in the time it takes the photons to go from your screen to your eyes. (Light travels at about 30cm/1ft per nanosecond)
  - xpil 3y ago
    Not to mention eons required for our optical organics to start registering the photons!
    - IanCal 3y ago
      The race is about to begin. I wait for the screen to flash green, finger hovering over the enter key. It flashes and I press the button immediately, and the race is over. In this time, my year old consumer graphics card has performed more floating point calculations than my entire town could in their entire lives. Occasionally I work this stuff out and it's frankly hard or impossible to truly appreciate just how fast these things are. (36 TFlops, 250ms reaction time = 9e12 calculations. One calculation every four seconds from birth to age 100 for 10,000 people is about 8e12 in total)
      - SamBankmanFried 3y ago
        And once you understand how fast modern computers are, you realize how absurd it is when software is still slow. How is it that Microsoft Teams takes 15 seconds to load? How many billions of calculations does it take to put a list of names on the screen? Never forget what they took from you.
        tialaramex 3y ago
        Although it can be laziness/ incompetence wasting cycles, sometimes the problem is that only the CPU got so much faster, and only in certain ways. If Teams talks to a remote server, doesn't matter how fast your CPU is, it takes time for the question to get to the server, time to get back, that's some time regardless. Now yes, maybe they write code which goes Hi! / Yes? / I'm a Teams client / That's nice / And you? / I'm the Teams server, what username? / SamBankmanFried / OK, and password? / Hunter2 / OK, you're logged in SamBankmanFried / OK do I have new #catpics ? / Nope / How about #emergency ? / Nope / How about #general ? / Yes, six messages ... And that's a lot of round trips whereas they could have done: Hi, I'm a Teams client, hopefully you're a Teams server / Yes, I'm the Teams server, what username & password ? / SamBankmanFried password Hunter2, also summarise my new stuff / Hello SamBankmanFried, you have six #general messages ... Which is far fewer round trips.
      - Arrath 3y ago
        > The race is about to begin. I wait for the screen to flash green, finger hovering over the enter key. It flashes and I press the button immediately, and the race is over. And you missed your window to get into BIOS, you need to reboot and try again. /s
        ByThyGrace 3y ago
        I'm fairly sure this is more than one somebody's recurring nightmare.
        lazide 3y ago
        No lie, my eye twitched.
  - p-e-w 3y ago
    My understanding is that this puts a fundamental limit on how fast CPU clocks can be. If the CPU die has a diameter of 3 centimeters, and the clock speed is a hypothetical 20 GHz, light (and electrical signals) can traverse at most half the size of the die in the course of one clock cycle. It's hard to imagine how such a CPU could work, since components at opposite sides of the die cannot communicate within a cycle.
    - HALtheWise 3y ago
      Definitely nitpicking here, but for a modern pipelined CPU there's already lots of components of the die that aren't designed to be able to exchange data within a single clock. I don't see what would be fundamentally different about laying out a CPU die such that operations that need to happen in the same clock are physically nearby, and it seems like it would (at worst) have similar properties to multi-socket and pipelined CPUs today where cache coherency operations and branch mispredictions have multi-cycle penalties associated with them. I'm pretty sure that multi-socket CPUs can't talk in less than one clock cycle anyway.
      - laci37 3y ago
        I only had an intro course in CPU architecture, but AFAIK pipelining depends on parts of the pipeline running on the same clock. I'd say CPU manufacturers already sidestepped this limitation by using multicore dies.
        foobiekr 3y ago
        No, it doesn’t. Putting aside that there is an entire field of clockless designs, asynchronous logic, free-running clocks, etc. You should think of this as “when the cpu is processing an instruction, what does it need to track to dispatch and retire it?” Designing to a click tick is one version and kind of where things were in the 1970s. It’s an educational model.
        Dylan16807 3y ago
        That just means you can't have a single simple clock source fan out in a simple way across the entire chip, but that kind of design performs badly anyway. There are lots of ways to have multiple clock sources kept in sync or to alter the clock's phase to compensate for distance, so you can keep the entire CPU synchronized even if crossing it takes multiple clock cycles.
  - _x11l 3y ago
    In game development we can abuse this fact with things like client-side prediction in authoritative online environs. The server plays along with the client in a no-graphics mode and plays the inputs from the client, validates said moves on the server, and if all goes well sends back the response allowing for client action all before the blink of an eye. In the case of an invalid move, the server yanks the client back to the state preceeding. Pair that with some lag compensation and you've got yourself a stew.
    - csomar 3y ago
      Do you have more detailed links about that?
      - eXpl0it3r 3y ago
        There's a great article by Valve: https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking https://developer.valvesoftware.com/wiki/Source_Multiplayer_...
      - goolz 3y ago
        The Valve paper posted is amazing but huge shoutout to Photon (not affiliated) as their docs break it down really well. Their Bolt and now Fusion offerings are a boon! https://doc.photonengine.com/fusion/current/tutorials/host-mode-basics/3-prediction https://doc.photonengine.com/fusion/current/tutorials/host-m...
    - swyx 3y ago
      what kind of latency budget do you have to do all that? even at like 15fps i cant imagine that you can provide a non janky experience when this “server yanks client back to valid state” move is done. i mean obviously you guys have figured it out, just the math doesnt quite make sense to someone like me not in gaming
      - qingdao99 3y ago
        Not an expert but: The lag compensation is, more intuitively, just allowing the client to move on its own without needing server verification yet. The server maintains the authoritative game state, but (assuming no cheating is going on) the clients are able to move as they think they will. In the background, the client is actually sending its inputs to the server, and they technically haven't happened until the server verifies them (however many milliseconds later), but we allow the client to move on its own regardless. The yanking back only happens if the client's new state (position etc.) don't match the server's state.
  - runlaszlorun 3y ago
    Was going to say the same. My mind was fairly blown when I realized that light only travels approx 4 inches in a clock cycle. Then again, every time my computer pauses for multiple seconds, me knowing how many billions of clocks cycles I’m waiting for doesn’t help my already challenged patience… haha.
- ByThyGrace 3y ago
  And then you factor in the occurrence of different systems running at different clock speeds having to interchange across several interfaces in a way that the entire communication somehow stays afloat and even produces feedback.
jxf 3y ago
This was beautiful. Two things stood out to me: * There's more stuff than I expected which exists only for backwards compatibility. That's a lot of bytes when you add it all up over the whole Internet. * There's a lot of "expect N more bytes for a data structure of type T1" messages followed immediately by "expect N-k more bytes for a data structure of type T1::T2". I assume this is because there's other stuff that could go in that spot, but it still looks strange. I'm sure all of this is necessary and important; I just found it really fascinating to peek under the covers. It's nice to be able to have it all (mostly) just work thanks to the tireless efforts of many engineers and protocol developers.
- codeflo 3y ago
  That kind of stuff is necessary for binary protocols to evolve in a compatible way. When a TLS 1.4 is defined, we need a window where clients and servers can still negotiate 1.3 until both have been upgraded. And 1.3 had to find ways to be compatible with 1.2, and so forth. Decades of that kind of evolution are guaranteed to leave some marks in the protocol. But let's keep a sense of proportion. I find it hard to worry about "wasting" maybe 0.01% of the total internet bandwidth for a few extra bytes here or there, when that's necessary to keep the internet working at all, when on the other hand, for no end-user benefit, we don't hesitate to waste maybe 15% (after compression) by insisting on using text-based formats for the payload in all our web standards. In fact, I'd love to see a back-of-the-envelope calculation of how many tons of CO2 would have been saved in total if HTML was a well-engineered binary format. (Including bandwidth, storage, parsing on the client etc.) The number must be insane.
  - maccard 3y ago
    The thing about html is that it's a verbose text format on the surface, but it compresses incredibly easily, and support for gzip is widespread. If you're concerned about size, brotli is better again.
    - codeflo 3y ago
      > The thing about html is that it's a verbose text format on the surface, but it compresses incredibly easily, and support for gzip is widespread. If you're concerned about size, brotli is better again. That's why I said it wastes 15%, not 100%. Whenever text-based formats and binary formats are compared, the results after compression (of both) are usually in that range. You can debate those precise numbers, they might be lower for the brotli/HTML combination. That won't really change the point I was making in context: That a few extra bytes for backwards compatibility in the TLS handshake pale in comparison to the amount of waste we accept for encoding the payload.
globalise83 3y ago
Very good! This would be very helpful for students on every "intro to networks" course on computer science courses as a way to visualise something that can seem very abstract.
- electrosphere 3y ago
  The Cisco Packet Tracer software is also good for this, as is Wireshark.
jpopesculian 3y ago
Very cool! Reminds me of the illustrated TLS connection which was a helpful resource for me when I had to implement a variation of it. https://tls12.xargs.org/ https://tls12.xargs.org/
- FujiApple 3y ago
  Great resource, thanks for sharing.
- lucidyan 3y ago
  > https://tls12.xargs.org/ https://tls12.xargs.org/ in the first paragraph on the page there is this link: > It’s inspired by [The Illustrated TLS 1.3 Connection](https://tls13.xargs.org/ https://tls13.xargs.org/) and Julia Evans’ [toy TLS 1.3](https://jvns.ca/blog/2022/03/23/a-toy-version-of-tls/ https://jvns.ca/blog/2022/03/23/a-toy-version-of-tls/).
codemanjoe 3y ago
Nice, super helpful for cs students.
amelius 3y ago
Since they add annotations to what is actually loaded, shouldn't the loading continue forever?
- laszlokorte 3y ago
  If the annotations were added by the server, yes. Not if they are added client side.
- H8crilA 3y ago
  This site is fetched twice, once by your browser, and another time by the JS code after you press the button. For example the JS loader specifies that only one cipher suite is to be used (TLS_AES_128_GCM_SHA256 ), while your browser will definitely support more than one. Any additional traffic is again fetched by your browser.
captn3m0 3y ago
The subtls hack is an amazing idea. I’ve been wanting to build a TLS Playground for a while(play around with CAs, Cert Issuance, Client Certs etc) and this would be great for it.
- gmac 3y ago
  Subtls author and OP here. That sounds great — feel free to ping me if useful! (Assemble these into an email address: george mackerron com).
  - webprofusion 3y ago
    Would be good to be able to point at any domain, a common issue with debugging cert stuff is working out which cert is being presented, TLS level, cipher suites etc are being negotiated.
    - gmac 3y ago
      That’s true, but I was wary of running what would essentially be an open TCP relay. Also, I don’t currently bundle a comprehensive set of root certs in subtls, nor support all ciphers or signing methods.
H8crilA 3y ago
I couldn't quite follow the symmetric key derivation. First there's something called "handshake key computations", which generates a full set of encryption and mac keys. It seems to be entirely based on secp256r1 (NIST P-256) key share. I understand that this part is not protected against man-in-the-middle, right? Then there's "application key computations", what are those values computed from? This process creates another complete set of encryption and authentication keys, and I assume this set is protected against man-in-the-middle.
- gmac 3y ago
  You might find this useful (it was a helpful source when implementing): https://tls13.xargs.org/ https://tls13.xargs.org/. Both sets of keys should be MITM-proof.
  - H8crilA 3y ago
    Thanks for the link. But I believe that the first set of keys/IVs is not protected whatsoever. Anyone can run the "Server Key Exchange Generation", as it doesn't require any secrets such as certificate private keys, only random inputs. EDIT: Specifically, at least up to this point anyone can impersonate the server.
    - tialaramex 3y ago
      Yes, maybe it's easier to understand what's going on once you understand the strategy in terms of a conversation. Suppose I'm Alice and I want to securely talk to Bob with TLS 1.3 The key exchange (KEX) allows me to agree a secret S with somebody I'm talking to over the network. I don't know if they're Bob, but whoever they are, eavesdroppers can't discover this secret. Now, we (Alice, and the maybe Bob) can communicate securely with our secret S, nobody can MITM this conversation, they don't know S. Bob sends public documents (a certificate) which say Bob knows some Private Key such that I can verify it with a published Public Key mentioned in the certificate. That's no big deal, they're public documents, anybody could have those but then... Bob also sends a transcript. The transcript is of our KEX earlier, and it's signed using Bob's private key, which means I, Alice, can verify this is a signed transcript of our conversation. I was in the conversation, so I can confirm it's identical. Having verified this signed transcript, I know that Bob was in the conversation I had earlier, with the unknown maybe-Bob, and it stands to reason that's because this is Bob. Notice that if Mallory, a hypothetical MITM, tried to attack us, this won't work. The conversation between me (Alice) and Mallory must involve parameters that Mallory chose, if Mallory just forwards Bob's parameters to Alice and vice versa, Mallory doesn't learn S and so is cut out of the picture. But, if Mallory changes the parameters Alice and Bob see, then the transcript that Bob signed won't match the KEX that Alice experienced, so the connection is aborted.
emielm 3y ago
This brings back memories of when I created a webbased version of spotify[1], using their (custom) encrypted protocol over TCP[2]. Notably: back then I used flash to speak TCP, with a memory-leaky and bug-ridden mechanism to transfer byte buffers between JS and Flash. [1] https://news.ycombinator.com/item?id=2556118 https://news.ycombinator.com/item?id=2556118 [2] https://github.com/EmielM/spotifyontheweb-crypt https://github.com/EmielM/spotifyontheweb-crypt
- swyx 3y ago
  how did you reverse engineer a custom encrypted protocol? i wouldnt even know where to begin.
globular-toast 3y ago
This reminds me of when I first discovered Wireshark (called Ethereal back then). It's always a good day when I have to break it out and still fun. I would try to reverse engineer the protocols. It's nice to see the annotations here as a lot of it doesn't make much sense without it.
simonjgreen 3y ago
Not trying to diminish it's importance, however isn't it slightly sad how much total payload is devoted to encryption? Also, and I know this is slightly pedantic, but this is only speaking to layer 7. If you really wanted to watch everything byte by byte you'd need everything upwards of layer 2 where we go from bits on wire to bytes and frames. If you've not used Wireshark before run it yourself and load some pages.
- tomtomtom777 3y ago
  I don't think much is wasted on encryption. Most is wasted on backwards compatibility in the form of negotiating protocols, algorithm, extenstions, etc. If there would forever be only one encryption algorithm in use we we wouldn't need most of the stuff.
  - segfaultbuserr 3y ago
    > If there would forever be only one encryption algorithm in use we we wouldn't need most of the stuff. Coincidentally, this is why a protocol like WireGuard is much simpler than OpenVPN. It's a clean-sheet design, so its developers had the luxury to design it with hardcoded modern crypto primitives without any revision or extension. Protocol negotiation is skipped entirely since it's often error-prone and suspect to attacks...
    - diarrhea 3y ago
      How will we go to newer Wireguard versions then? Throw it all away and use a wholly new product? Or have a Wireguard 2.0, where all participants need to upgrade in lockstep, with no backwards compatibility (actually sounds attractive: some churn from time to time, but none of the avoidable headaches)?
      - segfaultbuserr 3y ago
        > Or have a Wireguard 2.0, where all participants need to upgrade in lockstep, with no backwards compatibility (actually sounds attractive: some churn from time to time, but none of the avoidable headaches)? I think it's basically the plan. Even with protocol negotiation, replacing an existing crypto algorithm would be a breaking change anyway. Furthermore, it should be possible to preserve backward compatibility using a reserved field without a heavy-weight, full-fledged protocol negotiation. Entering a different code path if the message is tagged "version 2" should be enough.
webprofusion 3y ago
This is great, would be useful to be able to point it at any domain.
- webprofusion 3y ago
  For those looking for in-depth info on TLS, see also https://www.feistyduck.com/books/bulletproof-tls-and-pki/ https://www.feistyduck.com/books/bulletproof-tls-and-pki/
vrglvrglvrgl 3y ago
[dead]
can16358p 3y ago
While we all (HN audience) know roughly what kind of things are going on, seeing it in all the delicate details is fascinating. Just thinking that all these bytes and everything that's happening have 6 more layers below all the way to physical electrical/electromagnetic flow, all routed potentially through many different ISP backbones and possibly international routes, all happening in roughly less than 1/10 of a second is even more fascinating.
- connordoner 3y ago
  Incredible, really, isn't it?
- deleted 3y ago
  [deleted]
- nomel 3y ago
  The craziest thing is, if you’re using Ethernet, there’s a very high chance you have an actual physical data connection with the other computer on the other side of the world. A giant physical web blanketing the Earth.
  - vikingerik 3y ago
    Well, that's not new with computers or the internet. We had that ever since the analog telephone system. Even telegraphs before that for a smaller set of points and routes.
    - nomel 3y ago
      I imagine we're somewhere near peak density though, or maybe even past it. Wireless will slowly remove your fingers from laying on that physical web.
      - LK5ZJwMwgBbHuVI 3y ago
        Why isn't wireless physical? Perhaps it's not massive :)
hashhar 3y ago
Contrasting this with what happens over plain HTTP would be fascinating as well.
- gmac 3y ago
  Well, the equivalent for plain HTTP is very short. Client sends the GET request, shown near the end, and server sends back the payload, same as you see decrypted.
xpe 3y ago
84 76 68 82 (ASCII for “TLDR”)
jeroenhd 3y ago
I'm annoyed TLS 1.2 compatibility mode is still required. Is there a way to turn it off, accepting that people with incompetent network administrators can't access your website, or have shitty middleboxes forever ruined TLS?
- defluct 3y ago
  You can definitely just require TLS 1.3 with no backwards compatibility.
- gammalost 3y ago
  The problem is that you do not know where the middleboxes are. Removing support might therefore block users in weird and silent ways. The middlebox might be out of the users control and then nothing can be done to solve it. Blocking TLS 1.2 from a small blog is no big deal, but not something FAANG can risk One way of solving this is by circumventing the middleboxes. This is more or less the way QUIC works. QUIC uses UDP which avoid most middleboxes and their failed attempts at being helpful. So QUIC can without issue upgrade to a new version of TLS without middleboxes ruining it, while TLS over TCP is stuck (at least for the moment). This brings with it other issues, but hey one problem solved at least.
  - jeroenhd 3y ago
    If TLS 1.3 will fail, I doubt QUIC will make it through. I'm no fortune 100 sysadmin but if I were that worried about network traffic, I wouldn't allow some unknown UDP protocol to go out unnoticed. I don't know where these middleboxes are but this doesn't seem that important until people report having issues. It's been five years since TLS 1.3 was introduced and even longer since the survey that led to the compatibility mode was conducted, many companies with bad middleboxes will probably have had to upgrade them by now.
    - gammalost 3y ago
      It's not a problem of being paranoid about TLS. It's a problem with well intended middleboxes which worked at the time, but now do harm instead. It's easy to say that people should of updated by know. But that's hard to force when nobody fully knows what will break ( ipv4 to ipv6 for example). QUIC works better becuase UDP haven't gotten the same treatment as TCP and TLS. It brings with it other problems . One problem for example being NAT's sometimes poor handling of long lasting UDP connections. But QUIC has functionality to handle that. > I wouldn't allow some unknown UDP protocol to go out unnoticed A bit of a compromise has been made in this regard by using something called a spin bit. https://greenbytes.de/tech/webdav/draft-ietf-quic-spin-exp-latest.html https://greenbytes.de/tech/webdav/draft-ietf-quic-spin-exp-l...
bollwarm 3y ago
Maybe there should be a diagram to show the processes in the right
mvandermeulen 3y ago
Does anyone know what the NEL and Report-To headers are about/purpose?
- gmac 3y ago
  https://developers.cloudflare.com/support/network/understanding-network-error-logging/ https://developers.cloudflare.com/support/network/understand...
joelrwilliams1 3y ago
The secret life of packets.
waboremo 3y ago
Absurdly fascinating. I should probably stop reloading the site now! Also is there a reason why on HN this domain just shows itself as "pages.dev"? That's the root of Cloudflare Pages, so probably best to also show the subdomain for it like HN does for github.io
- 8organicbits 3y ago
  I wonder if its an out of date public suffix list? Thats how I'd decide when to show a subdomain. pages.dev was added a few years back: https://github.com/publicsuffix/list/pull/1093 https://github.com/publicsuffix/list/pull/1093
  - tialaramex 3y ago
    The people responsible for the PSL existing would like everybody to stop inventing more uses for it. That is, this is clearly a terrible idea but it is better than nothing, so here it is, but please invent something that's not a terrible idea.
    - 8organicbits 3y ago
      Are you sure? Looking at their website[1] I see: > Highlight the most important part of a domain name in the user interface Which is my suggestion above. > If you are using it for something else, you are encouraged to tell us, because it helps us to assess the potential impact of changes Which sounds cautiously supportive of additional use cases. [1] https://publicsuffix.org/ https://publicsuffix.org/
      - tialaramex 3y ago
        Ryan Sleevi has written about this before on Hacker News and here's his list https://github.com/sleevi/psl-problems https://github.com/sleevi/psl-problems It's definitely possible that Ryan would consider using this for HN a reasonable choice, because it's mostly cosmetic, but in general you should just not add more dependencies.
runlaszlorun 3y ago
That’s pretty neat. I’m all for things that make these systems more visual. I do chuckle that, for all of the advancements we’ve made with the web and 3D graphics, we’re still mostly worried about stringing together little squiggly characters and writing test cases or print statements to see what’s actually going on.
JadeNB 3y ago
Revealing my non-nerd credentials: when I click "Get this page, byte by byte" I just see: > We begin the TLS handshake by sending a client hello message (source): and nothing else seems to happen, no matter how long I wait. I thought I might have to click the button again, but it just seems to display the same message, no matter how often I click it. What else should I be doing?
- gmac 3y ago
  Huh, that’s odd. Are you able to open your browser dev tools and check for JS errors in the console?
  - JadeNB 3y ago
    I tried in Firefox, Safari, and Chrome. Here it is from Chrome: > index.js:2231 WebSocket connection to 'wss://ws.manipulexity.com/v1?address=subtls.pages.dev:443' failed: > ws @ index.js:2231 > index.js:2235 ws error: Event [I didn't expand this, but let me know if you need it] > connection closed index.js:2238
    - gmac 3y ago
      Hmm. Could you be behind some kind of interfering proxy that doesn't like WebSockets? Does this demo page work for you? https://libwebsockets.org/testserver/ https://libwebsockets.org/testserver/
      - JadeNB 3y ago
        > Hmm. Could you be behind some kind of interfering proxy that doesn't like WebSockets? I'm at work, so it's possible, but I'm not sure. > Does this demo page work for you? https://libwebsockets.org/testserver/ https://libwebsockets.org/testserver/ It shows me a rapidly incrementing number, that resets when I click "reset counter". Nothing obviously happens when I click "send junk". Is that what should happen?
      - JadeNB 3y ago
status200 3y ago
As a network guy I am blissed out by this, thank you for sharing. Often when I study the concepts I repeatedly have that same shock of how much is going on under the hood across large distances at tremendous speed.
BrandoElFollito 3y ago
Very nice, thank you. There is an older document (2009) which I liked very much and which taught me the details of a HTTPS connection (in a quite leisury way): http://www.moserware.com/2009/06/first-few-milliseconds-of-https.html http://www.moserware.com/2009/06/first-few-milliseconds-of-h...
diginova 3y ago
As a Computer Science undergrad student we just finished our course on Computer Networks in Depth along with Cryptography and it feels really good to be able to at least know what is going on in every output step of the page. Amazing demonstration for beginners! Thank you for sharing btw I was thinking if we had a visual interface with the request details (as in local switch, router, which AS, DNS or host is the request at) then it might be even more intuitive and easy to learn/understand. I don't think the exact private position of the packet can be traced that easily on a web request, but if it can then it probably might already be out there somewhere.
kulahan 3y ago
lol, this page did not work at all for me, and the only addon I have on firefox is ublock origin, which I disabled to no avail. Did anyone else find a workaround?
- sjnonweb 3y ago
  working for me with ublock origin enabled
tonymet 3y ago
awesome work. It’s a bit of intersection of instructional material, technical material and art. TLS debugging is infamous and this goes a long way to improve understanding. great work here
menus 3y ago
This was cool. Are there other tools/websites like this?
TrackerFF 3y ago
I remember back in the day some software companies typically used to ask a question like "What happens (under to hood) when you type in a URL in your web browser, and hit enter?" and you'd have to jog them through every step you could remember. This takes it to the next level.
er4hn 3y ago
Would this make it a TLS quine?
firstlink 3y ago
Ugh TLS certificates are such flaming garbage. There is zero reason for them to be in a machine-first protocol like ASN. Here we are with billions of computers spewing human-first protocols like JSON at each other and we can't even use it for human-only info like TLS certificate fields. But of course the complete incomprehensibility of TLS certs is a feature, not a bug: creating and signing your own is so difficult and arcane that it generates business for certificate vendors, even for certs for private use.
- 8organicbits 3y ago
  > even for certs for private use. This has been a concern of mine. Paired with incompatibility in clients[1] it's easy to mess up. I'm building a service[2] and related tooling that makes it easier to use public CAs for private use. I'm in early stages, but feedback has been good so far. [1] https://alexsci.com/blog/name-non-constraint/ https://alexsci.com/blog/name-non-constraint/ [2] https://alexsci.com/blog/improve-https-1/ https://alexsci.com/blog/improve-https-1/
westurner 3y ago
https://github.com/jawj/subtls https://github.com/jawj/subtls (A proof-of-concept TypeScript TLS 1.3 client) is implemented with the SubtleCrypto API. TIL about SubtleCrypto https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypto https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypt... : > The SubtleCrypto interface of the Web Crypto API provides a number of low-level cryptographic functions. Access to the features of SubtleCrypto is obtained through the subtle property of the Crypto object you get from the crypto property. decrypt() deriveBits() deriveKey() digest() encrypt() exportKey() generateKey() importKey() sign() unwrapKey() verify() wrapkey() Can SubtleCrypto accelerate any of the W3C Verifiable Credential Data Integrity 1.0 APIs? vc-data-integrity: https://w3c.github.io/vc-data-integrity/ https://w3c.github.io/vc-data-integrity/ ctrl-f "signature suite" > ISSUE: Avoid signature format proliferation by using text-based suite value The pattern that Data Integrity Signatures use presently leads to a proliferation in signature types and JSON-LD Contexts. This proliferation can be avoided without any loss of the security characteristics of tightly binding a cryptography suite version to one or more acceptable public keys. The following signature suites are currently being contemplated: eddsa-2022, nist-ecdsa-2022, koblitz-ecdsa-2022, rsa-2022, pgp-2022, bbs-2022, eascdsa-2022, ibsa-2022, and jws-2022. But what about "Kyber, NTRU, {FIPS-140-3}? [TLS1.4/2.0?]" i.e. PQ Post-Quantum signature suites? Why don't those need to be URIs, too?
w8730787298 3y ago
Hack game Ff

1341 points by gmac 3y ago

This is a really beautiful way to see something we take for granted all the time. The fact that computers can do all this in the blink of an eye (sans network speed) is just mind blowing.

IanCal 3y ago
One kinda related thing I find constantly amazing is that your processor running at x GHz will have had several more ticks in the time it takes the photons to go from your screen to your eyes. (Light travels at about 30cm/1ft per nanosecond)
- xpil 3y ago
  Not to mention eons required for our optical organics to start registering the photons!
  - IanCal 3y ago
    The race is about to begin. I wait for the screen to flash green, finger hovering over the enter key. It flashes and I press the button immediately, and the race is over. In this time, my year old consumer graphics card has performed more floating point calculations than my entire town could in their entire lives. Occasionally I work this stuff out and it's frankly hard or impossible to truly appreciate just how fast these things are. (36 TFlops, 250ms reaction time = 9e12 calculations. One calculation every four seconds from birth to age 100 for 10,000 people is about 8e12 in total)
    - SamBankmanFried 3y ago
      And once you understand how fast modern computers are, you realize how absurd it is when software is still slow. How is it that Microsoft Teams takes 15 seconds to load? How many billions of calculations does it take to put a list of names on the screen? Never forget what they took from you.
      - tialaramex 3y ago
        Although it can be laziness/ incompetence wasting cycles, sometimes the problem is that only the CPU got so much faster, and only in certain ways. If Teams talks to a remote server, doesn't matter how fast your CPU is, it takes time for the question to get to the server, time to get back, that's some time regardless. Now yes, maybe they write code which goes Hi! / Yes? / I'm a Teams client / That's nice / And you? / I'm the Teams server, what username? / SamBankmanFried / OK, and password? / Hunter2 / OK, you're logged in SamBankmanFried / OK do I have new #catpics ? / Nope / How about #emergency ? / Nope / How about #general ? / Yes, six messages ... And that's a lot of round trips whereas they could have done: Hi, I'm a Teams client, hopefully you're a Teams server / Yes, I'm the Teams server, what username & password ? / SamBankmanFried password Hunter2, also summarise my new stuff / Hello SamBankmanFried, you have six #general messages ... Which is far fewer round trips.
    - Arrath 3y ago
      > The race is about to begin. I wait for the screen to flash green, finger hovering over the enter key. It flashes and I press the button immediately, and the race is over. And you missed your window to get into BIOS, you need to reboot and try again. /s
      - ByThyGrace 3y ago
        I'm fairly sure this is more than one somebody's recurring nightmare.
        lazide 3y ago
        No lie, my eye twitched.
- p-e-w 3y ago
  My understanding is that this puts a fundamental limit on how fast CPU clocks can be. If the CPU die has a diameter of 3 centimeters, and the clock speed is a hypothetical 20 GHz, light (and electrical signals) can traverse at most half the size of the die in the course of one clock cycle. It's hard to imagine how such a CPU could work, since components at opposite sides of the die cannot communicate within a cycle.
  - HALtheWise 3y ago
    Definitely nitpicking here, but for a modern pipelined CPU there's already lots of components of the die that aren't designed to be able to exchange data within a single clock. I don't see what would be fundamentally different about laying out a CPU die such that operations that need to happen in the same clock are physically nearby, and it seems like it would (at worst) have similar properties to multi-socket and pipelined CPUs today where cache coherency operations and branch mispredictions have multi-cycle penalties associated with them. I'm pretty sure that multi-socket CPUs can't talk in less than one clock cycle anyway.
    - laci37 3y ago
      I only had an intro course in CPU architecture, but AFAIK pipelining depends on parts of the pipeline running on the same clock. I'd say CPU manufacturers already sidestepped this limitation by using multicore dies.
      - foobiekr 3y ago
        No, it doesn’t. Putting aside that there is an entire field of clockless designs, asynchronous logic, free-running clocks, etc. You should think of this as “when the cpu is processing an instruction, what does it need to track to dispatch and retire it?” Designing to a click tick is one version and kind of where things were in the 1970s. It’s an educational model.
      - Dylan16807 3y ago
        That just means you can't have a single simple clock source fan out in a simple way across the entire chip, but that kind of design performs badly anyway. There are lots of ways to have multiple clock sources kept in sync or to alter the clock's phase to compensate for distance, so you can keep the entire CPU synchronized even if crossing it takes multiple clock cycles.
- _x11l 3y ago
  In game development we can abuse this fact with things like client-side prediction in authoritative online environs. The server plays along with the client in a no-graphics mode and plays the inputs from the client, validates said moves on the server, and if all goes well sends back the response allowing for client action all before the blink of an eye. In the case of an invalid move, the server yanks the client back to the state preceeding. Pair that with some lag compensation and you've got yourself a stew.
  - csomar 3y ago
    Do you have more detailed links about that?
    - eXpl0it3r 3y ago
      There's a great article by Valve: https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking https://developer.valvesoftware.com/wiki/Source_Multiplayer_...
    - goolz 3y ago
      The Valve paper posted is amazing but huge shoutout to Photon (not affiliated) as their docs break it down really well. Their Bolt and now Fusion offerings are a boon! https://doc.photonengine.com/fusion/current/tutorials/host-mode-basics/3-prediction https://doc.photonengine.com/fusion/current/tutorials/host-m...
  - swyx 3y ago
    what kind of latency budget do you have to do all that? even at like 15fps i cant imagine that you can provide a non janky experience when this “server yanks client back to valid state” move is done. i mean obviously you guys have figured it out, just the math doesnt quite make sense to someone like me not in gaming
    - qingdao99 3y ago
      Not an expert but: The lag compensation is, more intuitively, just allowing the client to move on its own without needing server verification yet. The server maintains the authoritative game state, but (assuming no cheating is going on) the clients are able to move as they think they will. In the background, the client is actually sending its inputs to the server, and they technically haven't happened until the server verifies them (however many milliseconds later), but we allow the client to move on its own regardless. The yanking back only happens if the client's new state (position etc.) don't match the server's state.
- runlaszlorun 3y ago
  Was going to say the same. My mind was fairly blown when I realized that light only travels approx 4 inches in a clock cycle. Then again, every time my computer pauses for multiple seconds, me knowing how many billions of clocks cycles I’m waiting for doesn’t help my already challenged patience… haha.
ByThyGrace 3y ago
And then you factor in the occurrence of different systems running at different clock speeds having to interchange across several interfaces in a way that the entire communication somehow stays afloat and even produces feedback.

jxf 3y ago

This was beautiful. Two things stood out to me: * There's more stuff than I expected which exists only for backwards compatibility. That's a lot of bytes when you add it all up over the whole Internet. * There's a lot of "expect N more bytes for a data structure of type T1" messages followed immediately by "expect N-k more bytes for a data structure of type T1::T2". I assume this is because there's other stuff that could go in that spot, but it still looks strange. I'm sure all of this is necessary and important; I just found it really fascinating to peek under the covers. It's nice to be able to have it all (mostly) just work thanks to the tireless efforts of many engineers and protocol developers.

codeflo 3y ago
That kind of stuff is necessary for binary protocols to evolve in a compatible way. When a TLS 1.4 is defined, we need a window where clients and servers can still negotiate 1.3 until both have been upgraded. And 1.3 had to find ways to be compatible with 1.2, and so forth. Decades of that kind of evolution are guaranteed to leave some marks in the protocol. But let's keep a sense of proportion. I find it hard to worry about "wasting" maybe 0.01% of the total internet bandwidth for a few extra bytes here or there, when that's necessary to keep the internet working at all, when on the other hand, for no end-user benefit, we don't hesitate to waste maybe 15% (after compression) by insisting on using text-based formats for the payload in all our web standards. In fact, I'd love to see a back-of-the-envelope calculation of how many tons of CO2 would have been saved in total if HTML was a well-engineered binary format. (Including bandwidth, storage, parsing on the client etc.) The number must be insane.
- maccard 3y ago
  The thing about html is that it's a verbose text format on the surface, but it compresses incredibly easily, and support for gzip is widespread. If you're concerned about size, brotli is better again.
  - codeflo 3y ago
    > The thing about html is that it's a verbose text format on the surface, but it compresses incredibly easily, and support for gzip is widespread. If you're concerned about size, brotli is better again. That's why I said it wastes 15%, not 100%. Whenever text-based formats and binary formats are compared, the results after compression (of both) are usually in that range. You can debate those precise numbers, they might be lower for the brotli/HTML combination. That won't really change the point I was making in context: That a few extra bytes for backwards compatibility in the TLS handshake pale in comparison to the amount of waste we accept for encoding the payload.

globalise83 3y ago

Very good! This would be very helpful for students on every "intro to networks" course on computer science courses as a way to visualise something that can seem very abstract.

electrosphere 3y ago
The Cisco Packet Tracer software is also good for this, as is Wireshark.

jpopesculian 3y ago

Very cool! Reminds me of the illustrated TLS connection which was a helpful resource for me when I had to implement a variation of it. https://tls12.xargs.org/ https://tls12.xargs.org/

FujiApple 3y ago
Great resource, thanks for sharing.
lucidyan 3y ago
> https://tls12.xargs.org/ https://tls12.xargs.org/ in the first paragraph on the page there is this link: > It’s inspired by [The Illustrated TLS 1.3 Connection](https://tls13.xargs.org/ https://tls13.xargs.org/) and Julia Evans’ [toy TLS 1.3](https://jvns.ca/blog/2022/03/23/a-toy-version-of-tls/ https://jvns.ca/blog/2022/03/23/a-toy-version-of-tls/).

codemanjoe 3y ago

Nice, super helpful for cs students.

amelius 3y ago

Since they add annotations to what is actually loaded, shouldn't the loading continue forever?

laszlokorte 3y ago
If the annotations were added by the server, yes. Not if they are added client side.
H8crilA 3y ago
This site is fetched twice, once by your browser, and another time by the JS code after you press the button. For example the JS loader specifies that only one cipher suite is to be used (TLS_AES_128_GCM_SHA256 ), while your browser will definitely support more than one. Any additional traffic is again fetched by your browser.

captn3m0 3y ago

The subtls hack is an amazing idea. I’ve been wanting to build a TLS Playground for a while(play around with CAs, Cert Issuance, Client Certs etc) and this would be great for it.

gmac 3y ago
Subtls author and OP here. That sounds great — feel free to ping me if useful! (Assemble these into an email address: george mackerron com).
- webprofusion 3y ago
  Would be good to be able to point at any domain, a common issue with debugging cert stuff is working out which cert is being presented, TLS level, cipher suites etc are being negotiated.
  - gmac 3y ago
    That’s true, but I was wary of running what would essentially be an open TCP relay. Also, I don’t currently bundle a comprehensive set of root certs in subtls, nor support all ciphers or signing methods.

H8crilA 3y ago

I couldn't quite follow the symmetric key derivation. First there's something called "handshake key computations", which generates a full set of encryption and mac keys. It seems to be entirely based on secp256r1 (NIST P-256) key share. I understand that this part is not protected against man-in-the-middle, right? Then there's "application key computations", what are those values computed from? This process creates another complete set of encryption and authentication keys, and I assume this set is protected against man-in-the-middle.

gmac 3y ago
You might find this useful (it was a helpful source when implementing): https://tls13.xargs.org/ https://tls13.xargs.org/. Both sets of keys should be MITM-proof.
- H8crilA 3y ago
  Thanks for the link. But I believe that the first set of keys/IVs is not protected whatsoever. Anyone can run the "Server Key Exchange Generation", as it doesn't require any secrets such as certificate private keys, only random inputs. EDIT: Specifically, at least up to this point anyone can impersonate the server.
  - tialaramex 3y ago
    Yes, maybe it's easier to understand what's going on once you understand the strategy in terms of a conversation. Suppose I'm Alice and I want to securely talk to Bob with TLS 1.3 The key exchange (KEX) allows me to agree a secret S with somebody I'm talking to over the network. I don't know if they're Bob, but whoever they are, eavesdroppers can't discover this secret. Now, we (Alice, and the maybe Bob) can communicate securely with our secret S, nobody can MITM this conversation, they don't know S. Bob sends public documents (a certificate) which say Bob knows some Private Key such that I can verify it with a published Public Key mentioned in the certificate. That's no big deal, they're public documents, anybody could have those but then... Bob also sends a transcript. The transcript is of our KEX earlier, and it's signed using Bob's private key, which means I, Alice, can verify this is a signed transcript of our conversation. I was in the conversation, so I can confirm it's identical. Having verified this signed transcript, I know that Bob was in the conversation I had earlier, with the unknown maybe-Bob, and it stands to reason that's because this is Bob. Notice that if Mallory, a hypothetical MITM, tried to attack us, this won't work. The conversation between me (Alice) and Mallory must involve parameters that Mallory chose, if Mallory just forwards Bob's parameters to Alice and vice versa, Mallory doesn't learn S and so is cut out of the picture. But, if Mallory changes the parameters Alice and Bob see, then the transcript that Bob signed won't match the KEX that Alice experienced, so the connection is aborted.

emielm 3y ago

This brings back memories of when I created a webbased version of spotify[1], using their (custom) encrypted protocol over TCP[2]. Notably: back then I used flash to speak TCP, with a memory-leaky and bug-ridden mechanism to transfer byte buffers between JS and Flash. [1] https://news.ycombinator.com/item?id=2556118 https://news.ycombinator.com/item?id=2556118 [2] https://github.com/EmielM/spotifyontheweb-crypt https://github.com/EmielM/spotifyontheweb-crypt

swyx 3y ago
how did you reverse engineer a custom encrypted protocol? i wouldnt even know where to begin.

globular-toast 3y ago

This reminds me of when I first discovered Wireshark (called Ethereal back then). It's always a good day when I have to break it out and still fun. I would try to reverse engineer the protocols. It's nice to see the annotations here as a lot of it doesn't make much sense without it.

simonjgreen 3y ago

Not trying to diminish it's importance, however isn't it slightly sad how much total payload is devoted to encryption? Also, and I know this is slightly pedantic, but this is only speaking to layer 7. If you really wanted to watch everything byte by byte you'd need everything upwards of layer 2 where we go from bits on wire to bytes and frames. If you've not used Wireshark before run it yourself and load some pages.

tomtomtom777 3y ago
I don't think much is wasted on encryption. Most is wasted on backwards compatibility in the form of negotiating protocols, algorithm, extenstions, etc. If there would forever be only one encryption algorithm in use we we wouldn't need most of the stuff.
- segfaultbuserr 3y ago
  > If there would forever be only one encryption algorithm in use we we wouldn't need most of the stuff. Coincidentally, this is why a protocol like WireGuard is much simpler than OpenVPN. It's a clean-sheet design, so its developers had the luxury to design it with hardcoded modern crypto primitives without any revision or extension. Protocol negotiation is skipped entirely since it's often error-prone and suspect to attacks...
  - diarrhea 3y ago
    How will we go to newer Wireguard versions then? Throw it all away and use a wholly new product? Or have a Wireguard 2.0, where all participants need to upgrade in lockstep, with no backwards compatibility (actually sounds attractive: some churn from time to time, but none of the avoidable headaches)?
    - segfaultbuserr 3y ago
      > Or have a Wireguard 2.0, where all participants need to upgrade in lockstep, with no backwards compatibility (actually sounds attractive: some churn from time to time, but none of the avoidable headaches)? I think it's basically the plan. Even with protocol negotiation, replacing an existing crypto algorithm would be a breaking change anyway. Furthermore, it should be possible to preserve backward compatibility using a reserved field without a heavy-weight, full-fledged protocol negotiation. Entering a different code path if the message is tagged "version 2" should be enough.

webprofusion 3y ago

This is great, would be useful to be able to point it at any domain.

webprofusion 3y ago
For those looking for in-depth info on TLS, see also https://www.feistyduck.com/books/bulletproof-tls-and-pki/ https://www.feistyduck.com/books/bulletproof-tls-and-pki/

vrglvrglvrgl 3y ago

[dead]

can16358p 3y ago

While we all (HN audience) know roughly what kind of things are going on, seeing it in all the delicate details is fascinating. Just thinking that all these bytes and everything that's happening have 6 more layers below all the way to physical electrical/electromagnetic flow, all routed potentially through many different ISP backbones and possibly international routes, all happening in roughly less than 1/10 of a second is even more fascinating.

connordoner 3y ago
Incredible, really, isn't it?
deleted 3y ago
[deleted]
nomel 3y ago
The craziest thing is, if you’re using Ethernet, there’s a very high chance you have an actual physical data connection with the other computer on the other side of the world. A giant physical web blanketing the Earth.
- vikingerik 3y ago
  Well, that's not new with computers or the internet. We had that ever since the analog telephone system. Even telegraphs before that for a smaller set of points and routes.
  - nomel 3y ago
    I imagine we're somewhere near peak density though, or maybe even past it. Wireless will slowly remove your fingers from laying on that physical web.
    - LK5ZJwMwgBbHuVI 3y ago
      Why isn't wireless physical? Perhaps it's not massive :)

hashhar 3y ago

Contrasting this with what happens over plain HTTP would be fascinating as well.

gmac 3y ago
Well, the equivalent for plain HTTP is very short. Client sends the GET request, shown near the end, and server sends back the payload, same as you see decrypted.

xpe 3y ago

84 76 68 82 (ASCII for “TLDR”)

jeroenhd 3y ago

I'm annoyed TLS 1.2 compatibility mode is still required. Is there a way to turn it off, accepting that people with incompetent network administrators can't access your website, or have shitty middleboxes forever ruined TLS?

defluct 3y ago
You can definitely just require TLS 1.3 with no backwards compatibility.
gammalost 3y ago
The problem is that you do not know where the middleboxes are. Removing support might therefore block users in weird and silent ways. The middlebox might be out of the users control and then nothing can be done to solve it. Blocking TLS 1.2 from a small blog is no big deal, but not something FAANG can risk One way of solving this is by circumventing the middleboxes. This is more or less the way QUIC works. QUIC uses UDP which avoid most middleboxes and their failed attempts at being helpful. So QUIC can without issue upgrade to a new version of TLS without middleboxes ruining it, while TLS over TCP is stuck (at least for the moment). This brings with it other issues, but hey one problem solved at least.
- jeroenhd 3y ago
  If TLS 1.3 will fail, I doubt QUIC will make it through. I'm no fortune 100 sysadmin but if I were that worried about network traffic, I wouldn't allow some unknown UDP protocol to go out unnoticed. I don't know where these middleboxes are but this doesn't seem that important until people report having issues. It's been five years since TLS 1.3 was introduced and even longer since the survey that led to the compatibility mode was conducted, many companies with bad middleboxes will probably have had to upgrade them by now.
  - gammalost 3y ago
    It's not a problem of being paranoid about TLS. It's a problem with well intended middleboxes which worked at the time, but now do harm instead. It's easy to say that people should of updated by know. But that's hard to force when nobody fully knows what will break ( ipv4 to ipv6 for example). QUIC works better becuase UDP haven't gotten the same treatment as TCP and TLS. It brings with it other problems . One problem for example being NAT's sometimes poor handling of long lasting UDP connections. But QUIC has functionality to handle that. > I wouldn't allow some unknown UDP protocol to go out unnoticed A bit of a compromise has been made in this regard by using something called a spin bit. https://greenbytes.de/tech/webdav/draft-ietf-quic-spin-exp-latest.html https://greenbytes.de/tech/webdav/draft-ietf-quic-spin-exp-l...

bollwarm 3y ago

Maybe there should be a diagram to show the processes in the right

mvandermeulen 3y ago

Does anyone know what the NEL and Report-To headers are about/purpose?

gmac 3y ago
https://developers.cloudflare.com/support/network/understanding-network-error-logging/ https://developers.cloudflare.com/support/network/understand...

joelrwilliams1 3y ago

The secret life of packets.

waboremo 3y ago

Absurdly fascinating. I should probably stop reloading the site now! Also is there a reason why on HN this domain just shows itself as "pages.dev"? That's the root of Cloudflare Pages, so probably best to also show the subdomain for it like HN does for github.io

8organicbits 3y ago
I wonder if its an out of date public suffix list? Thats how I'd decide when to show a subdomain. pages.dev was added a few years back: https://github.com/publicsuffix/list/pull/1093 https://github.com/publicsuffix/list/pull/1093
- tialaramex 3y ago
  The people responsible for the PSL existing would like everybody to stop inventing more uses for it. That is, this is clearly a terrible idea but it is better than nothing, so here it is, but please invent something that's not a terrible idea.
  - 8organicbits 3y ago
    Are you sure? Looking at their website[1] I see: > Highlight the most important part of a domain name in the user interface Which is my suggestion above. > If you are using it for something else, you are encouraged to tell us, because it helps us to assess the potential impact of changes Which sounds cautiously supportive of additional use cases. [1] https://publicsuffix.org/ https://publicsuffix.org/
    - tialaramex 3y ago
      Ryan Sleevi has written about this before on Hacker News and here's his list https://github.com/sleevi/psl-problems https://github.com/sleevi/psl-problems It's definitely possible that Ryan would consider using this for HN a reasonable choice, because it's mostly cosmetic, but in general you should just not add more dependencies.

runlaszlorun 3y ago

That’s pretty neat. I’m all for things that make these systems more visual. I do chuckle that, for all of the advancements we’ve made with the web and 3D graphics, we’re still mostly worried about stringing together little squiggly characters and writing test cases or print statements to see what’s actually going on.

JadeNB 3y ago

Revealing my non-nerd credentials: when I click "Get this page, byte by byte" I just see: > We begin the TLS handshake by sending a client hello message (source): and nothing else seems to happen, no matter how long I wait. I thought I might have to click the button again, but it just seems to display the same message, no matter how often I click it. What else should I be doing?

gmac 3y ago
Huh, that’s odd. Are you able to open your browser dev tools and check for JS errors in the console?
- JadeNB 3y ago
  I tried in Firefox, Safari, and Chrome. Here it is from Chrome: > index.js:2231 WebSocket connection to 'wss://ws.manipulexity.com/v1?address=subtls.pages.dev:443' failed: > ws @ index.js:2231 > index.js:2235 ws error: Event [I didn't expand this, but let me know if you need it] > connection closed index.js:2238
  - gmac 3y ago
    Hmm. Could you be behind some kind of interfering proxy that doesn't like WebSockets? Does this demo page work for you? https://libwebsockets.org/testserver/ https://libwebsockets.org/testserver/
    - JadeNB 3y ago
      > Hmm. Could you be behind some kind of interfering proxy that doesn't like WebSockets? I'm at work, so it's possible, but I'm not sure. > Does this demo page work for you? https://libwebsockets.org/testserver/ https://libwebsockets.org/testserver/ It shows me a rapidly incrementing number, that resets when I click "reset counter". Nothing obviously happens when I click "send junk". Is that what should happen?
    - JadeNB 3y ago

status200 3y ago

As a network guy I am blissed out by this, thank you for sharing. Often when I study the concepts I repeatedly have that same shock of how much is going on under the hood across large distances at tremendous speed.

BrandoElFollito 3y ago

Very nice, thank you. There is an older document (2009) which I liked very much and which taught me the details of a HTTPS connection (in a quite leisury way): http://www.moserware.com/2009/06/first-few-milliseconds-of-https.html http://www.moserware.com/2009/06/first-few-milliseconds-of-h...

diginova 3y ago

As a Computer Science undergrad student we just finished our course on Computer Networks in Depth along with Cryptography and it feels really good to be able to at least know what is going on in every output step of the page. Amazing demonstration for beginners! Thank you for sharing btw I was thinking if we had a visual interface with the request details (as in local switch, router, which AS, DNS or host is the request at) then it might be even more intuitive and easy to learn/understand. I don't think the exact private position of the packet can be traced that easily on a web request, but if it can then it probably might already be out there somewhere.

kulahan 3y ago

lol, this page did not work at all for me, and the only addon I have on firefox is ublock origin, which I disabled to no avail. Did anyone else find a workaround?

sjnonweb 3y ago
working for me with ublock origin enabled

tonymet 3y ago

awesome work. It’s a bit of intersection of instructional material, technical material and art. TLS debugging is infamous and this goes a long way to improve understanding. great work here

menus 3y ago

This was cool. Are there other tools/websites like this?

TrackerFF 3y ago

I remember back in the day some software companies typically used to ask a question like "What happens (under to hood) when you type in a URL in your web browser, and hit enter?" and you'd have to jog them through every step you could remember. This takes it to the next level.

er4hn 3y ago

Would this make it a TLS quine?

firstlink 3y ago

Ugh TLS certificates are such flaming garbage. There is zero reason for them to be in a machine-first protocol like ASN. Here we are with billions of computers spewing human-first protocols like JSON at each other and we can't even use it for human-only info like TLS certificate fields. But of course the complete incomprehensibility of TLS certs is a feature, not a bug: creating and signing your own is so difficult and arcane that it generates business for certificate vendors, even for certs for private use.

8organicbits 3y ago
> even for certs for private use. This has been a concern of mine. Paired with incompatibility in clients[1] it's easy to mess up. I'm building a service[2] and related tooling that makes it easier to use public CAs for private use. I'm in early stages, but feedback has been good so far. [1] https://alexsci.com/blog/name-non-constraint/ https://alexsci.com/blog/name-non-constraint/ [2] https://alexsci.com/blog/improve-https-1/ https://alexsci.com/blog/improve-https-1/

westurner 3y ago

https://github.com/jawj/subtls https://github.com/jawj/subtls (A proof-of-concept TypeScript TLS 1.3 client) is implemented with the SubtleCrypto API. TIL about SubtleCrypto https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypto https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypt... : > The SubtleCrypto interface of the Web Crypto API provides a number of low-level cryptographic functions. Access to the features of SubtleCrypto is obtained through the subtle property of the Crypto object you get from the crypto property. decrypt() deriveBits() deriveKey() digest() encrypt() exportKey() generateKey() importKey() sign() unwrapKey() verify() wrapkey() Can SubtleCrypto accelerate any of the W3C Verifiable Credential Data Integrity 1.0 APIs? vc-data-integrity: https://w3c.github.io/vc-data-integrity/ https://w3c.github.io/vc-data-integrity/ ctrl-f "signature suite" > ISSUE: Avoid signature format proliferation by using text-based suite value The pattern that Data Integrity Signatures use presently leads to a proliferation in signature types and JSON-LD Contexts. This proliferation can be avoided without any loss of the security characteristics of tightly binding a cryptography suite version to one or more acceptable public keys. The following signature suites are currently being contemplated: eddsa-2022, nist-ecdsa-2022, koblitz-ecdsa-2022, rsa-2022, pgp-2022, bbs-2022, eascdsa-2022, ibsa-2022, and jws-2022. But what about "Kyber, NTRU, {FIPS-140-3}? [TLS1.4/2.0?]" i.e. PQ Post-Quantum signature suites? Why don't those need to be URIs, too?

w8730787298 3y ago

Hack game Ff