-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Impl symmetric AES encryption on top of TcpStream #111
base: master
Are you sure you want to change the base?
Conversation
I'll get on this as soon as I can. |
Welcom to hematite_server @bheart and thanks for sending in this PR! You are right, Apparently io::copy can be used with slices too. Would that help? We probably should use |
Oh, I forgot! It'll would be a good thing to enable encryption iff |
Wasn't aware of |
Just to be sure, when you say |
Yea, don't Regardless, using an |
@bheart Yeah, |
@@ -68,7 +68,7 @@ impl World { | |||
} | |||
|
|||
#[allow(unreachable_code)] | |||
pub fn handle_player(&self, mut stream: TcpStream) -> io::Result<()> { | |||
pub fn handle_player(&self, mut stream: SymmStream) -> io::Result<()> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should change this to be a S: Read + Write
instead of TcpStream/SymmStream
so we can easily switch authenticated mode on/off
. /cc @fenhl
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That will be difficult to merge with your single-player branch, because of the try_clone
call.
I was thinking about introducing a TryClone
trait and implementing it for the SymmStream
, plus an additional PlainStream
which would do nothing but wrap the underlying TcpStream
.
So two structs, each with an inner TcpStream
, one for plaintext communication and one for encrypted communication.
Then S: Read + Write + TryClone
would work.
* The server generates a 1024-bit certificate and corresponding private key at startup which is used during the encryption handshake. * All connections are wrapped in the `SymmStream` type during login, after which all r/w's are passed through separate 128-bit AES ciphers (known as `Crypter`s in `openssl` crate.)
Uses rust-openssl as released on crates.io instead of pulling the revision from Github.
TcpStream
is wrapped in theSymmStream
type, after which all subsequent reads and writes are passed through two separate 128-bit AES ciphers (decrypter
andencrypter
respectively.)The clients response is not verified atm, since the
login::clientbound::Disconnect
packet isn't implemented (guessing it won't be long, since @toqueteos has made efforts towards encoding ChatJson?)The nonce isn't randomly generated either, which I suppose isn't strictly necessary, but would be nice to have. It's also how cuberite does it (kind of.)
I'm also not happy with overruling the compiler in terms of
Send
andSync
safety (see src/vanilla/server.rs), but I'm under the impression that theopenssl
crate is as thread safe as it can get, and that markingPKey
s as such is a non-issue (I could totally be wrong, I'm not particularly well versed in Rust.)Still to do:
verify_token
verify_token
as opposed to hardcoding it