Safe Rust is Safe, but UnSafe Rust isn't really safer than other languges.
If you had to create an internet facing http/https server and security is of the utmost importance, what crate would you use ?
1 Like
That seems like an odd statement to me.
All Rust programs will be using some unsafe deep in their bowels somewhere. Are you then suggesting the entire Rust project has failed as Rust is no safer than other languages?
One should not conflate memory safety, as offered by Rust, with security. Although memory safety certainly helps keep certain bugs out of ones code there are many ways to write safe code that is not secure.
Anyway, in Rocket I trust.
4 Likes
If usage of unsafe Rust results in a remote code execution in an public facing service -- then yes, the entire binary has failed.
Then I would split the service into a nested network of increasingly more trusted servers and services, where each server only exposes one port with a simple protocol to the server outside of it.
3 Likes
Are you suggesting something like:
- trust Rust tcp/udp stdlib
- trust Docker
- build services that do http/https/websocket/webrtc <-> tcp/udp, put these services in Docker
No. I mean physical machines with at least two NICs, one for outside and one for inside.
One example:
Server 1: Handle HTTPS requests, parse requests and pass validated requests in a simple format to server 2.
Server 2: Authenticate users, decrypt data with user key and validate transactions. Pass validated transactions to server 3.
Server 3: Parse and validate transactions and execute them.
I think we can all agree on that.
I don't think is supports the statement that " UnSafe Rust isn't really safer than other languges."
For example: If my program contains 1% unsafe code then I know where to look for potential memory use problem, likely it has been checked very carefully, and tested as well. As such I have high confidence my entire program is safe.
On the other hand, if my program is written in C++, say, then the whole program is unsafe (in the Rust sense). Have no idea where to look for potential memory use problems (except the entire source), likely it has not been checked very carefully, testing does not show up many such problems. As such I have a lot less confidence my entire program is safe.
Of course I can always screw up my programs logic so as to allow remote program execution, even without having unsafe in it.
5 Likes
We might have different definitions for 'unsafe Rust'; I am referring to only the unsafe blocks.
Ok.
Are you then suggesting you would not use any web server with a little unsafe block in it?
Or can we forget the unsafe discussion and just ask what is likely the most secure web server crate?
1 Like
I do not recall ever suggesting that.
A system is only as secure as its weakest link. Considering usage of unsafe , imho, is absolutely fair game when considering which crates to use for public facing services.
This is not necessarily true in the general case. It is possible to use weaker components safely, as long as the system is designed to never ask more of the weak component than it can give.
By analogy, consider a suspension bridge. Not all members need to be the same strength, as they each serve different roles. The foundation piers will be massive blocks of concrete, and the towers atop them will be made of large steel beams. Then there are the main cables, wide enough to have a walkway atop them, and the secondary cables are just a few inches in diameter.
This is more-or-less the approach that @s3bk is suggesting: The more complicated parts of your application will necessarily have weaker security due to a larger surface for bugs, so you should design your application to protect these weaker components with stronger ones.
10 Likes
I strongly object to the notion that using unsafe in strategic locations makes a project as unsafe as a C++ project. The entire point is that Rust makes it possible to encapsulate the unsafe in a way where it really does become safer than other languages.
18 Likes
To answer the actual question, I would probably go for something based on hyper, or even use hyper directly.
5 Likes
Ok. So a little unsafe is acceptable.
I'm not sure what a sensible answer could be. How should one rate the probability of one web server containing a security vulnerability vs another one?
If we knew of a vulnerability in some web server software that has not been fixed I guess we could say it has 100% probability of being insecure.
If we don't know of such a vulnerability then we can only ask, what is the probability that there is one in some web server. Zero chance, some chance, certain?
If vulnerabilities we being found and fixed everyday in web servers we could base our probability estimate on the rate at which they are discovered and the rate at which they are fixed. If a web server never has a CV found we might assign it a lesser probability of being insecure. I don't think we have enough (any?) such statistics to do this.
That leaves other ways to assess security that are less solid:
Who wrote it and what is their skill level and experience of security. Personally I think anything I wrote would be less secure than if it were written by someone who knows what they are doing,
How much unsafe does it have in it? As you hint, the more unsafe perhaps the higher the probability some mistake slipped through. But, as I said, unsafe is not the same as insecure. Or rather being safe does not imply secure. There are plenty of safe ways to write insecure code.
Other than the above, I don't know how we should assess security. Perhaps higher a bunch of security experts to review the code in minute detail.
I can't afford that so I rely on Sergio Benitez and Rocket.
2 Likes
If security is of the utmost importance I would use NGinx with CertBot to create a security layer outside of my program. Then I would use NGinx to route one open public port to my program, which would listen to a port on the system’s localhost. This has the added benefit of separating concerns: the secure server stuff and the business logic stuff aren’t mixed in your code.
1 Like
In rust I would personally be more worried about an http server crate incorrectly implementing the http protocol on semantic level allowing denial of service or causing some other kind of security issue not caused by memory safety than a bug in unsafe code causing an RCE or information leak on the server.
5 Likes
Is anyone making that argument?
Opening your question here with "Safe Rust is Safe, but UnSafe Rust isn't really safer than other languges." certainly suggests that you did. We can only read what you write, not what you are thinking.
3 Likes
I was always under the belief that 'unsafe Rust' refers to 'unsafe blocks of Rust code'. Both you and @Alice seem to be interpreting 'unsafe Rust' as 'all code in a Rust crate that has a single unsafe call'.
Ok. Now we know what you mean.
Does it matter if an HTTP(S) create has an unsafe block in it? Would that automatically cause you to rank it as less secure?