Hacker News Reader

Comment by gsa | Hacker News Reader

I have been researching VPN protocols that work in China and found that Xray [0] is the most recommended route to escape the GFW. An ideal VPN setup is one where packets appear as normal https traffic. Some VPN setups take it a step further and proxy the traffic through Cloudflare. Setting all this up is nowhere as easy as Wireguard. Coincidentally, I came across this project on Github earlier today which is an obfuscation proxy for Wireguard [1], but I haven't found any information about how well it works.

[0] https://github.com/XTLS/Xray-core

[1] https://github.com/database64128/swgp-go

View on HN

If everyone does this wouldn’t that encourage them to try to do carrier grade SSL decryption? I seem to recall that some country is already doing this and to get online you need to trust the state’s CA.

I would be interested to know which country this is

Here’s an article about Kazakhstan:

https://www.f5.com/labs/articles/threat-intelligence/kazakhs...

Kazakhstan? That attempt failed. I recently cataloged similar concerns[1].

[1] https://alexsci.com/blog/ca-trust/

Well, a long time back, there are proxies such as fqrouter, GoAgent and XX-NET which sends plain but loaded HTTP requests as transport. So I guess if a country decides to ban/decrypt TLS, people can just switch to another proxy/protocol.

Of course, both fqrouter and GoAgent is long gone by now and should not be used. However, it seems that XX-Net is still been actively developed and (according to their project page on GitHub) is currently give out one million free ChatGPT-3.5 tokens for it's paying user...(I mean like... what??? and why???)

X-ray is not the protocol. It’s called Trojan-gfw. X-ray a tool using it. The original (unmaintained) implementation: https://github.com/trojan-gfw/trojan

Is it possible to tunnel over SSH through GFW? User connects to server inside GFW, which tunnels outside, and onto the web?

Yes. I lived in China and that’s how I accessed the internet when my VPN got blocked. They block the port if you connect to it for too long though. Then you will no longer have ssh access to your server without a vpn.

I have noticed many new security and privacy oriented projects use Go and even C/C++.

Wasn't Rust supposed to be the language that should be used to write all security-critical software? What happened? Are crates like rustls/ring still intentionally sabotaging Rust's cryptographic ecosystem with their "we will always be pre-1.0.0 and never have a stable API" philosophy?

What if "C/C++" is not actually a thing and modern software engineering practices is what actually makes software safe? Writing modern C++ with good test coverage, sanitizers deployed and wrapping critical/unsafe parts into safe interfaces gets you _very_ far.

"Just don't write bugs", eh? :P

I don't necessarily disagree with you about C/C++ (or even Brainfuck) but some languages have the tendency to push you in the right direction and I've come to appreciate those more with time.

Unfortunately far too many people writing C++ are not writing modern C++. Most writing C with classes.

You can write memory unsafe code in rust, including memory management if you want - you just have to wrap it in unsafe which at least clues others in to watch this area carefully. In C++ you can put unsafe code anywhere. Sometimes unsafe is really needed, rust makes it hard enough to write unsafe code that you will only do that where you must and then jump back to safe code. In C++ you are likely to mix safe and unsafe code all over and that makes audits harder.

Wishing for something won't make it come true. C++ has had decades to get this to where it needs to be, there's no reason to hope that if we just give them another chance they'll get it right this time when you can instead use a language which got it right.

If we're talking about Go, the design of this language is perfect for writing a network related stuff, it's pretty easy, safe and stable. Language's stdlib is mature. As far as I know, in case of Rust you have to rely more on external libraries when you're writing network stuff to make development process less verbose and comfortable. Please, correct me if I'm wrong.

The std libraries in rust are sufficient for most things, but it’s definitely true there are very rich crates for networking with higher level semantics or specialized abilities (for instance async networking is generally done by bringing in tokio or something similar). In rust this isn’t considered bad, and in a lot of situations like embedded systems you don’t want or can’t use std because (for example) posix semantics aren’t available.

Personally I’m not a fan of batteries included languages because they inevitably suffer a Python heat death if standard libraries as the ecosystem improves faster without the baggage standard libraries carry intrinsically.

Hence, IMO the fact std provides a highly common and simple layer and external crates provide opinionated ergonomic interfaces is a feature, not a flaw, of rust. The crate ecosystem in rust is exceptionally good.

>Wasn't Rust supposed to be the language that should be used to write all security-critical software? What happened?

What does "supposed" mean in this case?

There's no one dictating what language "security-critical" or other software will be written. So, if it was "supposed", it was incorrectly supposed, by people reading some enthusiast posts about Rust and thinking it's adoption is inevitable or that it applies to everybody.

In real life, some went with Rust, others chose Go, and others C++, Java, etc.

>Are crates like rustls/ring still intentionally sabotaging Rust's cryptographic ecosystem with their "we will always be pre-1.0.0 and never have a stable API" philosophy?

That could help, but whether Rust has stable crypto crates or not, wouldn't change the fact that teams and projects will use what they wanna use, which is not necessarily Rust.

Just because some enthusiasts went "Rust all the things!" doesn't mean others will follow them.

Who would use unsafe Java to write "security-critical" software?

What do you mean by "unsafe Java"?? Do you mean Java as a language is somehow unsafe? I beg to disagree - it's one of the most scrutinized platforms you can find and widely used in all sorts of security critical software everywhere.

Java has soooo many security vulnerabilities - just browse around a bit...

"sooo many" is a technical term?

"Sooo many" compared to what? Did you scrutinize the equivalent of Java's SDK in Rust + extra crates to get the same functionality?

Do you include things like unrelated package bugs, like log4j bugs?

Hyperbola GNU/Linux ditched OpenJDK becasue either bugs or patents. The list on Java CVE's it's atrocious. Java should've died long ago with Golang and some cross-plaform (basic) GUI libraries promoted from Google. Nothing fancy, something like plan9/9front UI's, but enhanced.

Java exists today because of corporateware. Outside of it, it's dead. De-ad. No one uses Java seriously for emulators, browsers, or basic software. Just ad-hoc company-graded enterprise, live VB6 back in the day.

I don't think this take understands Java's position, relevance, or the roles it serves. Or even what are the important categories, driving most of software development (it's not enulators, broswers -of which they're just a handful, all in C++, or "basic software" whatever that means).

For starters, Java is by no means used just in "corporateware", if this means some intranet stuff. It's also hugely dominant in server side development (including FAANG) and is used by tons of startups, it's big in banking, high frequency trading, and all kinds of heavy service infrastructure.

That covers the huge majority of programming work, not writing "emulators and broswers" (sic), which is why it's in the top 5 of the TIOBE index.

"GUI libraries" have little to do with, not to mention they're generally irrelevant for most modern programming use cases, which is server/backend or web-based (and where they're not, they're already provided by the host OS and its preferred SDKs).

Also "Hyperbola GNU/Linux"? That yardstick of what's secure?

That doesn't say anything about CVE's and the issues on being not so performant against the new iterations of C# or even PHP >7.

I know that if you were to work in any company, Java would ve everywhere, but today the times changes. Even the Crustacean lang it's preferable againt Java on big backends. On the ligther workloads, Golang works great and it solves the multiplatform issue by crosscompiling from anywhere to anywhere.

These sound like musings based on "coolness factor" and hype, with a very distorted sense of the facts on the ground. Like the kind one gets from reading about various technologies or tinkering rather than actually working with them.

In any case, there's some serious lack of seriousness in the above. I mean, Java "not so performant against the new iterations of C# or even PHP >7"?

JetBrains is valued at $7 billion by the Bloomberg Billionaires Index and they build their popular IDEs in Java... So Java isn't de-ad outside of corporateware...

I know it's used by inertia in some corporate envs and thanks to some GC tunings it looks that it can run really well over long time. But even with GraalWM, the performance outside big irons leaves much to be desired...

Java works passably and gets job done over long time. And rust isn't magically fast.

You mean something like arbitrary deserialization? That's a logical bug implementable in any language.

That is because it is popular. Any language that was as popular as java for nearly 30 years will have a large collection of problems. Java avoids a large number of possible problems by being memory safe, but it doesn't avoid them all.

Java libraries with security holes aren't java.

I don't think you understand the words written yourself. At least provide some relevant, convincing examples instead of throwing these claims around.

I bet he understands Java fully but is just joking here to make a debate...

In what context do the words "unsafe Java" even begin to make sense?

Go and Rust are better at different things.

Go uses garbage collection, while Rust uses manual memory management with borrow-checking to ensure safety. Both are just as safe, but garbage collection is slower while Rust's manual memory management requires a lot more effort on the part of the developer. In particular, the performance of garbage collection is less predictable, making Go unsuitable for things like audio processing or video games, where you need to reliably deliver data every few milliseconds to avoid crackling audio or weird glitches. In Rust, you can predict exactly when memory will be freed, and if part of your code must always run in a predictable amount of time, this can be done. Go doesn't give you that guarantee. This isn't very important in traditional client-server apps, CLI tools etc, so go is usually fine for those.

In addition, Go requires a runtime, which is somewhat heavy. This makes it pretty unsuitable for kernels, software that runs on bare metal, microcontrollers etc. Rust doesn't have that problem.

However, Go is usually much faster to write in, as you don't have to worry about managing memory and proving to the borrow checker that you're doing it correctly. The fact that you have Goroutines instead of OS threads also makes it easier to handle lots of concurrent activities, like in a web app that concurrently handles many requests.

I don’t know what you mean by manual memory management. Memory management in rust is fully automated. The only manual thing is if you want to annotate lifetimes to ensure memory is available past implicit lifetimes, or if the line time of something can’t be automatically derived. Borrow semantics are not manual memory management. You don’t directly control when memory is freed in rust, but because it’s (often) stack based it’s usually pretty obvious memory is freed when the stack is unwound.

I feel like you’re confusing rust with c/c++ in this discussion.

I don’t find go faster to write in at all. I feel like they’re about the same, but I find go package management to be a mess and prefer cargo. Rust however does require you to be more aware of memory lifetime and ownership, and provides generally better performance in exchange.

> Both are just as safe

With a single execution context this is true. But, whereas you simply can't write data race bugs in Safe Rust† in Go you can write them and they blow up your safety guarantees. If you race something trivial Go promises (unlike C or C++) that this doesn't immediately set fire to the world, the raced trivial object (say, an integer) is ruined and you must not touch it, but if you stay away from that object your program has clearly defined behaviour. Unfortunately non-trivial objects (say, a slice) are immediately Undefined Behaviour when raced.

† This falls out of the mutability rules. A data race is when somebody else modifies something at "the same time" as you're using it, e.g. thread A changes actor to "Steve Buscemi" from "Susan Sarandon" at the same moment thread B is printing the actor out and oops, we write "Susan Sarcemin" or crash or something different happens, who knows. Rust says you can't have multiple aliases and mutability, so this never happens.

To be pedantic, Go strings are immutable and will carry different pointers to different underlying rune slices, so the reader would just display one string or the other, not "Susan Sarcemin".

That said, I'm not sure why developers freak out over races so much. Races that result in simple display of data that's one nanosecond old is typically not a failure condition in most applications. Actual failure conditions from races are usually from read-operate-writes like increments/decrements/etc. And for these, we have tons of solutions, anywhere from atomics to transaction contexts to CRDTs, etc.

> I'm not sure why developers freak out over races so much

In all languages if you cause a data race you lose Sequential Consistency. Java's experience teaches us that even if you go to extraordinary lengths to ensure that everything else is still fine, programmers cannot reason about non-trivial software without Sequential Consistency and so now they can't fix it. In something like C or C++ all races are Undefined Behaviour, all bets are off. In Go as we saw some data races aren't immediately dangerous but even if you're careful you do lose Sequential Consistency and so good luck doing anything when you don't understand what your program means any more.

> And for these, we have tons of solutions

If you put the solution in place and thus prevent a data race, you don't have a data race. Now, when was the last time you wrote a program in which you got everything right first time?

Do you need to imagine a vulnerability when we have a CVE database?

> To be pedantic, Go strings are immutable and will carry different pointers to different underlying rune slices,

I wasn't thinking specifically about Go for this example, but alas Go's strings aren't trivial objects, and so this data race would be immediate UB in Go, whereupon "Susan Sarcemin" while still very unlikely is not impossible. The text (underlying rune slices? really? I guess that would be on brand but it's a bad idea) isn't getting mutated, but your string typed value is, and that is a non-trivial object.

I don't know where you get your information from, but I don't think anyone links specific languages with security oriented projects.

rust was supposed to write excessive bloatware like servo at 50% quality, that's its killer feature

Reply on news.ycombinator.com