Hacker Newsnew | past | comments | ask | show | jobs | submit | capitol_'s commentslogin

At least here in Norway it has, it seems like it's not very difficult to put some cables in the ground and install a big pre built metal box :)

Most gas stations have them and there is also a lot of street charging stations.

But it's still cheapest to charge at home.


> it's not very difficult to put some cables in the ground and install a big pre built metal box :)

But increasingly it's becoming a problem that those cables have nowhere to run to as the grid isn't capable of serving them all. There might be excess generation but unless you have the capacity in the wires to get it where it's needed you're still stuck.

Especially in dense old cuties where the grid was built when the goal was to power a bunch of incandescent light bulbs. Not all the appliances we have today let alone cars with a battery capacity equal to a household's weekly usage of electricity when the grid was designed.


The problem can be alleviated with more chargers. If every parking spot had a charger you could slow-charge with much lower pressure on the grid. 2kW over night are plenty for most people’s driving needs.


You could but the customer seems to want as fast of a charge as possible...

Having driven an EV for over 10 years, I don't see why. There's plenty of places where you have the time but still.


>incandescent light bulbs

which are an order of magnitude less efficient than contemporary LED lights.


The whole point is that we used to assume that maybe 1 kW was sufficient. 6kW or 9kW isn't uncommon anymore, especially when you also use it for heating


Less efficient but still often having a better output over the frequency spectrum


It's much harder to make a magic juice that moves though the cables and boxes ;)


Is it really that much harder than making the magic juice that legacy cars run on? By now it is cheaper and less reliant on despots all over the world to get electricity than fuel in most of Europe I assume. Electricity is a great interface as well given the actual source of energy doesn't matter as much and is interchangeable.


The cooldown setting in dependabot solves this attack vector. By setting it you give security vendors time to scan new packages.


Notably this does nothing to "solve" the attack vector. You've got a live bomb in front of you and you're adding 10s to the countdown hoping that _others_* find it and defuse it in that time period.

I would challenge anyone proposing this to define more than one party doing security checks on packages to prove the point that many projects are waving their hands nebulously around saying "security vendors" and then YOLO'ing code into their codebase because they didn't here the muses wailing.

Alternatively from the other direction - Point to any dependency in your project. How can you get *POSITIVE SIGNAL* that security vendors _did_ look at it and okay it? How much scrutiny did they put into it? At what version did they last inspect it?


With today's AI glut of tokens, multiple someones are scanning security checks against the changed code. The real problem, as was before, was getting anybody anywhere to pay enough attention for long enough.


Only if their scanning detects it though. Malware authors have incentive to figure out how to fool the tool. They don't even need to be right all the time, any attack that survives works for them, and creating accounts is easy.


Shouldn't a perfect shuffle just reorder the cards without adding entropy?

You would need sloppy ones to introduce randomness.


A "perfect shuffle" according to the article:

>The riffle shuffle has to follow a realistic but strict model where cards are randomly interleaved from the left or right pile one by one. (Each card gets dropped from either the left or the right pile with a probability that’s proportional to the number of cards remaining in that pile. This means that the cards don’t simply alternate between left and right, which would result in a predictable structure; instead, the order might go “left, right, right, left, right, left, left.”)


It's modelled with randomness, each card is taken from left or right with a probability, it's not a deterministic model.


You misunderstood because the title is ambiguous.

This talks about seven consecutive riffle shuffles ("cut the deck and interleave the piles"): Those are not a "perfect shuffle" (i.e. same probability for every permutation) by themselves, only after doing them several times consecutively (which is kinda suprising by itself).


Yeah, a "perfect" shuffle is known as a faro shuffle and it's the basis of a lot of magic tricks, but it's a weird looking shuffle and it sort of ruins the tricks once you can recognize it.


not a lot of magic tricks. quite few actually. and it's interesting that it ruins the trick for you, because it's still a quite hard maneuver.

as a magician, I'm always still impressed when I see perfect faros.


Yeah, I worked on getting a Faro for a while when I was a teenager but gave up on it after a few months. I even got some coaching and tips from the Professor and Earl Nelson, so the issue was definitely not a lack of knowing the best ways it's ever been done :-). I just couldn't get it quite reliable enough to 100% trust in performance. Plus most of the Faro effects that were hot at the time were poker stacks and I was never really into those plots.

Now, all these decades later, I don't regret giving up on the Faro and a burnable 2nd. I got along just fine without either one as there's so many ways to reach the same destinations. It's weird how some moves just 'speak to you' right away and others never seem to sit right. Best advice I ever got was to not force it. If progress stalls out, just move on.

You going to Magic Live this year?


Yeah, I also cannot get a perfect faro consistently enough. I can consistently get 51 cards correct every time. It’s actually amazing how I am off by one every single one.

That’s a thing where when you know how hard the trick is, it makes it better.

Very cool your training.

And same on poker plots. I can do them infinite other cooler ways, so what’s the point?

The burnable 2nd I have. But it’s not the traditional 2nd. I have practiced and still practice the Richard Turner style 2nd, but I never do it in a performance. I use another path to get to the same result.

Wasn’t planning on Magic Live, but I should see where it is and when.


> I can consistently get 51 cards correct every time.

That's not a bug, it's a feature! Just do a "new deck order restore" with the selected card out of seq. :-)

> when you know how hard the trick is, it makes it better.

Totally! A few years ago I shared my view on "The Progression of Close-up Magic" (pardon the paste):

1. When you're 12, you're happy if a trick fools anyone.

2. Once you get older and have practiced a lot, you start to feel cocky that almost all your tricks fool almost everyone.

3. Then you keep practicing obsessively, start sessioning with good magicians and get humbled all over again. But in their work you start to realize there are levels of depth beyond just fooling people. You can finally see the path and your journey begins.

4. If you keep no-lifing it, eventually those magicians you respect, start respecting a few of your moves back. And that feels better than the loudest applause from any audience.

5. If you're a public performer, you're now probably working regularly. You fool all non-magicians all the time, and even other magicians some of the time. All your years of practice and study have finally paid off. Then you realize, most nights the valets make more than you do. :-)

6. But you keep doing it because you love it, except now the only audience you're working to impress is yourself. Non-magicians love it just as much whether you do easy tricks the easy way or hard tricks the hard way. In competent hands, they all look identical.

But you keep looking for even harder stuff, and then spend hours reworking the methods, exploring how to create the same effect in new ways. You sweat the meta stuff - structure, timing, flow. You pick up new subtleties by studying ancient VHS videos of the old masters. How Slydini's body language made his lapping transcendent. You contemplate how Goshman put that goddamn coin under a clear water glass, in the middle of an empty table, under a spotlight, with 80 year-old arthritic hands. And no one saw him do it. No trick, no move, just pure Jedi misdirection. And no audience will ever know the hours you waste obsessing on this. To everyone else, the tricks look exactly the same, but you do it your own weird, much harder way simply because you think it's neat, elegant, clever or sometimes just because it feels a little more right.

7. At that point, whether you keep working as a pro or even still perform magic at all becomes irrelevant. It's just a day job like any other. You do magic for yourself and maybe handful of others who 'get it'. The tech equivalent is kind of like the time I realized I'd spent more time (and had more fun) reading Doom's source code than I ever had playing the game.

> I can do them infinite other cooler ways, so what’s the point?

One cold deck is worth a thousand perfect Faros :-).

> Very cool your training.

I'd been obsessed with magic since I was 7 and was lucky enough to live in Los Angeles. When I was 16 I heard about the Magic Castle Junior program, then just in it's third year. When I auditioned, Vernon himself (then in his late 80s) was one of the three judges. No pressure, kid - it's just the guy that book you've had since you were 12 titled World's Greatest Magic says is "the greatest magician of the 20th century." The Castle Juniors was the hardest audition in magic because they lose money on (and have to mentor) every kid they let in. Three tricks, 10 minutes. I was so nervous, I blew two of my three tricks. Complete fail. I was so naive and stupid, all three tricks I picked were originals with insanely high difficulty. I had zero chance of nailing them under the pressure and lights of the Castle close-up gallery. :-)

I was shocked when I found out I'd gotten in on my first audition (the avg was 3). Vernon was at my first meeting, took me aside and made it very clear he'd voted against me because I "sucked." He blamed the other two other judges for being 'softies' who gave partial credit to my failed tricks because they were "mildly interesting" twists. Vernon stayed tough on me for all my years in the Juniors, but I did learn a lot from the cranky old bastard. Once when I was classic palming a coin, he slapped my hand and snorted "you palm like a girl!" Offended, I replied "At least the coin didn't fall out when you hit my hand." He rolled his eyes, and sighed "Kid, if you're doing it right, it should fall out!" Vernon passed away a few years after I turned 21 and became a regular member. It wasn't until I was invited to be a judge for regular member auditions that I learned Magic Castle auditions require that all three judges vote "Yes" to accept anyone. Vernon had lied to me! That was the moment I began to suspect maybe he didn't believe I was completely hopeless! I think he just saw how arrogant and cocky I was and knew I needed to be humbled before I could learn anything he had to teach. At best, Vernon seemed to find all the Juniors annoying, and at worst, insufferable. We used to wonder why he bothered showing up to every meeting since we were so hopeless. Only in later years did I appreciate the gift he was giving us and the legacy he was creating. That first decade of graduates from the Juniors created a shocking number of the top magical performers, creators and teachers in the world (although I don't count myself in that lofty company).

I 'dropped out' as a performer after 4 years working full-time as a pro to become a serial tech startup entrepreneur. A few years ago, Stan asked me to give the opening keynote at Magic Live to reflect on how, in my case, so much early magic potential and world-class mentoring "had gone so horribly wrong." :-) My conclusion was that learning the centuries-old craft, rigor and discipline of inventing all-new ways to make the impossible seem possible, and then the showmanship to present it well - was the best training possible for a successful career in tech.

> The burnable 2nd I have.

I'm envious. Mine's just ugly. I kept playing with it on and off over the years but when I saw Lennart Green do his (face up!) I officially gave up on it forever. :-) Of course, Vernon was one of the few humans ever to master a perfect burnable middle. But that's a god move beyond us mere mortals. (Excellent book on Vernon's years long journey to get that 'perfect middle': https://www.amazon.com/dp/0805074066).

> Wasn’t planning on Magic Live, but I should see where it is and when.

First week of August in Vegas (usually the same week as Blackhat). I go every year just to hang out with friends from the old days. Ping me if you go.


Very interesting story. I come from a different direction.

I work in tech, and was onsite somewhere for over a month with nothing to do. Remote area. I had always loved magic, and had asked magic teachers to teach me when I was a kid, and they all said no, they don't teach anyone.

I read books, but didn't really get it.

So I was in tech, in a place completely foreign to me with no rental car on weekends. I asked the bartender if he had anything I could do. He handed me a deck of cards.

From there, I just started to learn and practice things cause I was bored. Ultimately went to train with Jeff McBride and Eugene Burger. Jeff wasn't focused on the kinds of magic I liked, and Eugene Burger hated my style. I fooled both of them for the "final", intentionally leading Eugene down a garden path.

He hated not treated the cards with reverence. So I threw cards behind me, knowing it would completely shut off his brain while I did the secret move.

I did the same with Jeff. In the routine, I took his teaching on what not to do, and intentionally did it to shut off his brain.

They were both completely, ridiculously fooled. I likely may have fooled them without it, but I am too clever for my own good, and wanted to trick them in my own way.

From there, I ended up training with the guy who actually fit my style, Dani Daortiz. I flew to Spain and learned from him and Yann Frisch. I also helped Yann develop a new move. I taught them some of my original moves which they loved. I just come at things from a very different angle, so I have some interesting things.

Dani asked me to perform at the end, but I was too nervous. He is the guy I most adore. I regret that.

I even left them at one point after a full day of working with them, and just went and did magic in Spain for the night. I just do whatever, and that was what my soul needed after listening to 12 hours of magic discussion.

So I'm a software engineer, who has it as a hobby, but whenever I do it, I do it at a level that is stupid good. I don't even remember tricks, or have a set list, I just sort of vibe with whatever I remember, and rely on all the random skills I have to get there. I will do Lennart's snap deal for fun, invent a new trick on the spot because I'm bored. I do have a few original tricks that are completely mine.

One of them has a mind reading plot with cards. I have done the trick so many times in life, that I can legitimately forget the card, and it's fine, I can actually do the activity of figuring out their card without knowing it a good percentage of time.

You just get so used to understanding how people react to things, that you can figure it out in the process.

The trick just keeps evolving. Now, quite often, I have other spectators figure out the card. They also can get it with my... direction to what to look for.

So then they get to be the star. Lot of fun. It has so many variations because the whole thing is jazzed. So every time something new works, it's another thing I might remember to do.

I also am maybe the only magician then will intentionally bomb tricks. I learned early on that I do this for fun, and unfun people are not worth my time.

So even though I know the trick, and their card, I will intentionally pretend I don't and bomb the trick. I like that space. Living in that space has taught me more than any book about how to jazz around failure.

Intentionally failing is a master class in the space of failure in magic.

So I'm just a software engineer, who has had a ridiculously deep hobby for a long enough time that I can do a full show at a moment's notice. I have the tools, the understanding, and I can do prepared stuff, jazz whatever, or remember a trick i haven't done in 10 years, and decide to do that.

I do it for my fun. It's enabled me to drink for free where ever I go if I want, and have an enjoyable time.

I don't usually do the Magic Live stuff. I did that stuff for awhile, but I never felt like it really added much value to my experience.

I feel like I could surely if I cared to, book a show here locally, and do it. It would teach me a lot, but I just don't really want it. I like just being a random dude who can do ridiculously good magic when I feel like it.


I don’t know on perfect shuffles but for the sloppy shuffles, the deck is cut at a random location between each shuffle.


See the paragraph beginning "Yet terms and conditions also apply."


Just make a PR here: https://github.com/areweguiyet/areweguiyet

(I'm not affiliated, but have made PRs there in the past)


Why not use ripgrep?


I'm working with mostly "cattle"-type boxes with only the stock OS components installed so I "live off the land". On boxes that I treat as "pets" I do load other tools. A Win32 port of GNU grep has done well enough for me that I've never thought to look at ripgrep.


Isn't that just an insult people throw around? Or maybe some psychopath that tries to justify their worldview.

I have never had an conversation with someone who seems like an NPC.


I also find it useful for review, and sometimes I use multiple passes to review for different categories. Like security, performance and so on.


As far as I understood it: GnuPG started to implement stuff from the standard before it was finished, the standard continued to improve and GnuPG refused to change code already written.

Combined with some personal drama.


it's not that simple. the new standard is a complete rewrite of the old one. they are not even compatible anymore. things the old standard used to support are not supported in the new standard. that makes any implementation of the new standard incompatible with implementations of the old one. GnuPG simply refused to stop supporting the old standard and decided to fork the standard itself. on the personal drama my interpretation is that it resulted from people backing the new standard being unhappy that GnuPG didn't go along.

my opinion is that rewriting standards like that is the result of design by committee. everyone wants to put their mark on it. designing a new standard is fine, but the new standard should have also received a new name, or it should at least have been acknowledged that the old standard still needs to be supported until enough time has passed that the old standard is no longer in use. (which could take decades if not more if we want to be realistic and consider that encrypted data at rest could linger around pretty much forever unless actively re-encoded.)

(source: i talked to a GnuPG developer)


LibrePGP is also a rewrite. To keep supporting legacy v4 you have to keep having v4 code no matter if the new thing you add is v5 (LibrePGP) or V6 (the RFC)


actually neither are complete rewrites. i played around with diff and found that the new version of OpenPGP seems to keep about 60% of the old one and LibrePGP seems to keep 90%.

so the rewrite claim was exaggerated. i didn't compare the stuff that was added or merged.


The claim is even more exaggerated than that, because a lot of the diffs between 4880 and 9580 are editorial and structural, and don't have any semantic effect.


> the new standard is a complete rewrite of the old one. they are not even compatible anymore.

My honest first reaction to this statement would get me permabanned from this site, so here’s the polite version:

This is nonsense on stilts. It is so ill-informed and baseless I struggle to understand how anyone who has read the RFCs in question could possibly come to this conclusion. It is hooey.

> things the old standard used to support are not supported in the new standard.

Aside from deprecating some ancient cryptographic algorithms that nobody uses any more, everything from RFC4880 is in RFC9580. Can you point out a concrete example of something (non-obsolete!) that is missing?

> that makes any implementation of the new standard incompatible with implementations of the old one.

That is news to every openpgp implementation other than gnupg, which have happily implemented both. Even RNP have it in a feature branch somewhere.

> (source: i talked to a GnuPG developer)

Which one? When? It would genuinely help if they would go on the record. I strongly suspect their actual opinion would differ from what you’ve reported here. There’s enough hearsay nonsense about the schism floating around the internet as it is, without adding to it.


i appreciate you making the effort to register an account to make this comment. i have addressed some of the issues raised in a comment here: https://news.ycombinator.com/item?id=48058065

i hope you'll notice this reply and get a chance to read it.


Your first example sound very sensible to me?

Using new technology in something small and unimportant like a setup script is a perfect way to experiment and learn. It would be irresponsible to build something important as the first thing you do in a new language.


For your own use, yes.

But if you're working with others, you should default to using standard industry tools (absent a compelling reason not to) because your work will be handed off to others and passed on to new team members. It's unreasonable to expect that a new Windows or Linux sysadmin or desktop support tech must learn Rust to maintain a workstation setup workflow.


agreed. I think if we all went with this HN mindset of "html4 and PHP work just fine" we wouldn't have gone anywhere with regards to all the technical advancements we enjoy today in the software space


Finally encrypted client hello support \o/


Is this something that we can enable "today" or is it going to take 12 years for browsers and servers to support?


CloudFlare has supported it since 2023: https://blog.cloudflare.com/announcing-encrypted-client-hell... Firefox has had it enabled by default since version 119: https://support.mozilla.org/en-US/kb/faq-encrypted-client-he... so you can use it today.


"... so you can use it today."

What if he wanted to use it for requesting blog.cloudflare.com

   ;; ANSWER SECTION:
   blog.cloudflare.com. 300 IN HTTPS 1 . alpn="h3,h2" ipv4hint=104.18.28.7,104.18.29.7 ipv6hint=2606:4700::6812:1c07,2606:4700::6812:1d07
Where are the ECH keys

For example,

   ;; ANSWER SECTION:
   test.defo.ie. 300 IN HTTPS 1 . ech="AEb+DQBCqQAgACBlm7cfDx/gKuUAwRTe+Y9MExbIyuLpLcgTORIdi69uewAEAAEAAQATcHVibGljLnRlc3QuZGVmby5pZQAA"
or

   ;; ANSWER SECTION:
   cloudflare-ech.com. 300 IN HTTPS 1 . alpn="h3,h2" ipv4hint=104.18.10.118,104.18.11.118 ech="AEX+DQBBpQAgACB/RU5hAC5mXe3uOZtNY58Bc8UU1cd4QBxQzqirMlWZeQAEAAEAAQASY2xvdWRmbGFyZS1lY2guY29tAAA=" ipv6hint=2606:4700::6812:a76,2606:4700::6812:b76
It's true one can "use it today". One could use it for the past several years as well. The software has been around for a while

But ECH has never been consistently enabled for the general public beyond a small number of test sites that are only for testing ECH


https://tls-ech.dev indicates that Safari doesn't support it, but Chrome does.


That’s likely due to iOS/macOS not supporting it in production-default-enabled yet; there’s an experimental opt-in flag at the OS level, but Safari apparently hasn’t (yet) added a dev feature switch for it.

https://developer.apple.com/documentation/security/sec_proto...

Presumably anyone besides Safari can opt-in to that testing today, but I wouldn’t ship it worldwide and expect nice outcomes until (I suspect) after this fall’s 27 releases. Maybe someone could PR the WebKit team to add that feature flag in the meantime?


Nginx mainline 1.29.x supports it. So once you get that and also the openssl version on your system, good to go. Likely too late for ubuntu 26.04, maybe in debian 14 next year, or of course rolling release distros / containers.

But, in a personal/single website server, ech does not really add privacy, adversaries can still observe the IP metadata and compare what's hosted there. The real benefits are on huge cloud hosting platforms.


FWIW Nginx 1.30 [1] just released and supports it so most distributions will have support as soon as those responsible for builds and testing builds push it forward.

"Nginx 1.30 incorporates all of the changes from the Nginx 1.29.x mainline branch to provide a lot of new functionality like Multipath TCP (MPTCP)."

"Nginx 1.30 also adds HTTP/2 to backend and Encrypted Client Hello (ECH), sticky sessions support for upstreams, and the default proxy HTTP version being set to HTTP/1.1 with Keep-Alive enabled."

But, in a personal/single website server, ech does not really add privacy, adversaries can still observe the IP metadata and compare what's hosted there

I don't quite follow. I have dozens of throw-away silly hobby domains. I can use any of them as the outer-SNI. How is someone observing the traffic going to know the inner-SNI domain unless someone builds a massive database of all known inner+outer combinations which can be changed on a whim? ECH requires DOH so unless the ISP has tricked the user into using their DOH end-point they can't see the HTTPS resource record.

[1] - https://news.ycombinator.com/item?id=47770007


It's not that adversaries can directly see the domain name; this doesn't have anything to do with domain fronting. The issue is that ECH doesn't hide the server's IP address, so it's mostly useless for privacy if that IP address uniquely identifies that server. The situation where it helps is if the server shares that IP address with lots of other people, i.e., if it's behind a big cloud CDN that supports ECH (AFAIK that's currently just Cloudflare). But if that's the case, it doesn't matter whether Nginx or whatever other web server you run supports ECH, because your users' TLS negotiations aren't with that server, they're with Cloudflare.


I can't speak for anyone else but I think I can work around that by moving the site around to different VPS nodes from time to time. I get bored with my silly hobby sites all the time and nuke the VM's then fire them up later which gives them a new IP. I don't know what others might do if anything.

If I had a long running site I could do the same thing by having multiple font-end caching nodes using HAProxy or NGinx that come and go but I acknowledge others may not have the time to do that and most probably would not.


That's not quite it. The issue is that there's no other traffic bound to that IP - ECH doesn't buy you any security, because an observer doesn't even need to look at the content of the traffic to know where it's headed.


Maybe it will be more useful for outbound from NGinx or HAProxy to the origin server using ECH so the destination ISP has no idea what sites are on the origin assuming that traffic is not passing over a VPN already.


Anyone who wants to track your users can just follow the IP changes as they occur in real time.


Anyone who wants to track your users can just follow the IP changes as they occur in real time.

That's cool. I only make my own mini-CDN's.

There is always the option to put sites on a .onion domain but I don't host anything nearly exciting or controversial enough. For text that's probably a good option. I don't know if Tor is fast enough for binary or streaming sites yet. No idea how many here even know how to access a .onion site.

I will test out your theory and see if anyone bothers to track my IP addresses and does anything with them. I probably need to come up with something edgy that people would want to block. Idea's for something edgy?


Tor is completely usable at reasonable speeds by even normies via Brave.


That's kindof what I suspected but have not kept up with it.


Doesn't matter, I (not OP, but also operating VPS) still want to support this, so the clients can eventually assume all correctly configured servers support it.


TLS (the IETF Working Group not the protocol family named for them) have long experience with the fact that if you specify how B is compatible with A based on how you specified A and ship B what you did won't work because the middleboxes are all cost optimized and don't implement what you specified but instead whatever got the sale for the least investment.

So e.g. they'd work for exactly the way you use say TLS 1.0 in the Netscape 4 web browser which was popular when the middlebox was first marketed, or maybe they cope with exactly the features used in Safari but since Safari never sets this bit flag here they reject all connections with that flag.

What TLS learned is summarized as "have one joint and keep it well oiled" and they invented a technique to provide that oiling for one working joint in TLS, GREASE, Generate Random Extensions And Sustain Extensibility. The idea of GREASE is, if a popular client (say, the Chrome web browser) just insists on uttering random nonsense extensions then to survive in the world where that happens you must not freak out when there are extensions you do not understand. If your middlebox firmware freaks out when seeing this happen, your customers say "This middlebox I bought last week is broken, I want my money back" so you have to spend a few cents more to never do that.

But, since random nonsense is now OK, we can ship a new feature and the middleboxes won't freak out, so long as our feature looks similar enough to GREASE.

ECH achieves the same idea, when a participating client connects to a server which does not support ECH as far as it knows, it acts exactly the same as it would for ECH except, since it has neither a "real" name to hide nor a key to encrypt that name it fills the space where those would fit with random gibberish. As a server, you get this ECH extension you don't understand, and it is filled with random gibberish you also don't understand, this seems fine because you didn't understand any of it (or maybe you've switched it off, either way it's not relevant to you).

But for a middlebox this ensures they can't tell whether you're doing ECH. So, either they reject every client which could do ECH, which again that's how you get a bunch of angry customers, or, they accept such clients and so ECH works.


Even if the browsers and servers don't support it, you could still enable it because the system is designed to be backward compatible.


And QUIC.


Wasn't QUIC all done in the 3.x versions? Is there something in this release related to QUIC support?


Correct. 3.5 (the current LTS) included QUIC support: https://openssl.foundation/news/the-features-of-3-5-external...


Just be aware any reasonable network will block this.


Just be aware any reasonable network will block this.

Russia blocked it for Cloudflare because the outer SNI was obviously just for ECH but that won't stop anyone from using generic or throw-away domains as the outer SNI. As for reasonable I don't quite follow. Only censorious countries or ISP's would do such a thing.

I can foresee Firewall vendors possibly adding a category for known outer-SNI domains used for ECH but at some point that list would be quite cumbersome and may run into the same problems as blocking CDN IP addresses.


Once upon a time, "reasonable networks" blocked ICMP, too.

They were wrong then, of course, and they're still wrong now.


Once upon a time, like today? ICMP is most definitely only allowed situationally through firewalls today.


I'd say that ICMP is only situationally blocked by firewalls, not the other way around.

Because I can ping almost any public server on the internet and they will reply. I can ping your website just fine and it replies to me!


You'd say incorrectly, firewalls have an implicit deny rule, so any case ICMP traverses a firewall, someone wanted it to. Obviously large hosting providers tend to find value in ICMP being enabled.

But for example, our firewall at work responds to ICMP but all of the endpoints which aren't meant for public use do not. That is less because ICMP is a problem and more because everything works fine without it and least privilege is good design.

ICMP is also more than just ping, and some parts of ICMP are considered a vulnerability if exposed to the public internet by some scanning services.


The normal behavior is that firewalls and proxys respond to the ICMP requests instead of forwarding them though...


That kind of cargo culted tradition is how you end up with weird packet loss and VPNs that flat-out refuse to work.

I could be convinced to block inbound pings. Anything past that and I'd want solid evidence that it wouldn't break anything, with the expectation that it would.


address-mask-request and redirect and timestamp-request for IPv4 might be problematic to allow inbound from who knows where. echo-request might well be rate limited so remote hosts can ping certain servers (but not random client host IPs), but not too many pings per second.


Why is it "reasonable" to block it?


Well, I may want to have a say in what websites the employees at work access in their browsers. For example.


That’s not a meaningful issue here. Either snoop competently or snoop wire traffic, pick one.

In the snooping-mandatory scenario, either you have a mandatory outbound PAC with SSL-terminating proxy that either refuses CONNECT traffic or only allows that which it can root CA mitm, or you have a self-signed root CA mitm’ing all encrypted connections it recognizes. The former will continue functioning just fine with no issues at providing that; the latter will likely already be having issues with certificate-pinned apps and operating system components, not to mention likely being completely unaware of 80/udp, and should be scheduled for replacement by a solution that’s actually effective during your next capital budgeting interval.


That’s usually done not on the network side but through the device itself. Think MDM and endpoint management.


A good solution is tackling it on both. At work we have network level firewalls with separate policies for internal and guest networks, and our managed PCs sync a filter policy as well (through primarily for when those devices are not on our network). The network level is more efficient, easier to manage and troubleshoot, and works on appliances, rogue hardware, and other things that happen not to have client management.


Well, if you have MDM you should be able to just disable ECH.


This is also indeed done on both. Browser policies.


Any "reasonable" network just sees a regular Client Hello, the rest is encrypted. They designed it with your very concern in mind to obscure that the ECH even happens.


Procrastinators. FTFY.

Eventually these blocks won't be viable when big sites only support ECH. It's a stopgap solution that's delaying the inevitable death of SNI filtering.


This will never happen. Because between enterprise networks and countries with laws, ECH will end up blocked a lot of places.

Big sites care about money more than your privacy, and forcing ECH is bad business.

And sure, kill SNI filtering, most places that block ECH will be happy to require DPI instead, while you're busy shooting yourself in the foot. I don't want to see all of the data you transmit to every web provider over my networks, but if you remove SNI, I really don't have another option.


> Because between enterprise networks

> require DPI

Enterprises own the device that I'm connected to the network with, I don't see how you can get any more invasive than that.

> countries with laws

1) what countries do national-level SNI filtering, and 2) why are you using a hyptothetical authoritarian, privacy invading state actor as a good reason to keep plaintext SNI?

> Big sites care about money

Yes, and you could say that overbearing, antiquated network operators stop them from making more money with things like SNI filtering.


> I don't want to see all of the data you transmit to every web provider over my networks

Then don't look. I'm serious. This idea that corporations need to snoop on everything their employees do is disgusting.


So, if you are not at minimum inspecting SNI, you are not meaningfully providing security for your network. Where I work we do not really pay attention to what people are doing with their computers (that is an HR problem, not an IT problem), but the prevalence of ransomware almost certainly starts and ends with people not making rational network security decisions, which starts with filtering. We also remove the ads. =)


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: