mirror of
https://github.com/quasar/Quasar.git
synced 2026-04-25 23:35:58 +03:00
[GH-ISSUE #722] TLS connection problems #467
Labels
No labels
bug
bug
cant-reproduce
discussion
duplicate
easy
enhancement
help wanted
improvement
invalid
need more info
pull-request
question
wont-add
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/Quasar#467
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @mystyq on GitHub (Oct 28, 2018).
Original GitHub issue: https://github.com/quasar/Quasar/issues/722
In release mode, the client does not authorize with the server and will cause the server to stop listening upon connection.
Is this something that is currently still being implemented, or am I possibly not setting it up correctly?
@MaxXor commented on GitHub (Oct 28, 2018):
First compile client & server in release configuration. Then create a client from the included builder in the server. This way it should work I've tested it on my machine.
@mystyq commented on GitHub (Oct 28, 2018):
This is how I've done it as well. I've also tried running the server in debug mode and client in release (compiled). When I do this I get an AuthorizationException and both the certs are null
@MaxXor commented on GitHub (Oct 28, 2018):
Mixing up client and release mode is not supported. Hm, I'll check it again but I'm sure it was working before. :D
@MaxXor commented on GitHub (Oct 28, 2018):
Works fine on Windows 10. Do you use other OS?
@mystyq commented on GitHub (Oct 28, 2018):
I'm testing on W7 Virtual machine at the moment. For some reason the server is not stopping from listening now but the client is not connecting. I'm not sure what changed but I'll keep messing with it to see if I can get it working.
@MaxXor commented on GitHub (Oct 28, 2018):
You can still debug the release builds when enabling PDB-creation. Then just attach the VS debugger to the process and you should see the exceptions.
@mystyq commented on GitHub (Oct 29, 2018):
Thanks for that information.
I was able to get Quasar to work on my host machine. The VM is not connecting. (Both NAT and bridged modes)
@MaxXor commented on GitHub (Oct 29, 2018):
Can you open the TCP connection with netcat? If that doesn't work, it's a firewall/routing problem.
@mystyq commented on GitHub (Oct 29, 2018):
Getting a connection refused. I've turned the firewall off on the VM as well... No idea lol
@MaxXor commented on GitHub (Oct 29, 2018):
Then it's not a Quasar issue, this seems to be solved. Could you maybe explain what caused the certificate issues?
@mystyq commented on GitHub (Oct 30, 2018):
I will look into it, if I find anything I'll make it known
@mystyq commented on GitHub (Oct 30, 2018):
I haven't found the reason this is happening, however just to make a note - I tried using netcat again and was able to open the connection using the same command as above. The listen server stopped automatically when trying to send some data to the socket.
@MaxXor commented on GitHub (Oct 31, 2018):
Yes, it's not meant to receive some random data. Well, that's fixed now. Can you tell me if the client connection is now working to your VM?
->
ed1bf59155&e24b024554@mystyq commented on GitHub (Oct 31, 2018):
I can confirm that these changes fixed the problem with the listen server. It is no longer stopping after an unauthorized client tries to communicate. The client is not connecting to the server however. I've tried running the client on my host machine, connecting to a WAN address and running the server on the VMs (as well as loopback/DHCP addresses). I've tried using both VMware Workstation and Virtualbox with no luck. Both operating systems on the VMs are Windows 7.
@MaxXor commented on GitHub (Nov 1, 2018):
Okay, thanks for confirming. Can you confirm that the TCP port is still correctly opened by trying to connect via
netcaton the same machine you want to run the client on?@mystyq commented on GitHub (Nov 1, 2018):
netcat shows an open connection from host -> VM. VM is bridged to local network (for UPnP).
I downloaded 1.3.0.0 and it connected just fine on the VM.
@mystyq commented on GitHub (Nov 1, 2018):
Quasar (up-to-date) is working on a Windows 10 VM.
@cyclo-techtwister commented on GitHub (Nov 2, 2018):
seems it does not allow for loop back connections..
@MaxXor commented on GitHub (Nov 2, 2018):
@cyclo-techtwister That's not the same. loopback is localhost, he's trying to connect to a different host.
@cyclo-techtwister commented on GitHub (Nov 2, 2018):
OK, I to can't figure out why when using virtual machine old version works just fine but this newer one will not connect. I have no way of testing otherwise as using smartphone for internet and noway to port forward.. running on Windows 7 Oh, I did notice (newest version) that if GUI/server is running then client wouldn't even attempt to connect,port conflict? However like I mentioned older version runs and connects just fine.
@MaxXor commented on GitHub (Nov 2, 2018):
Before we continue here, you know that all old versions before 21st October 2018 are incompatible with the latest one? This means, old clients won't be able to connect to the latest server version. (there is a wiki page on how to update the clients)
@mystyq commented on GitHub (Nov 2, 2018):
https://stackoverflow.com/questions/52237532/sslstream-authenticateasclient-failure-only-on-windows-7-when-specifying-sslprot
A comment from a stack overflow post:
@mystyq commented on GitHub (Nov 2, 2018):
I ran procexp on the client. It sends SYNs to the server while it is not listening, however when the server is listening it doesn't even attempt to connect to the server.
@cyclo-techtwister commented on GitHub (Nov 2, 2018):
When using old or new versions I use respected servers I just assumed from the start that old clients would not work with newer code upgrades. Maybe it's a Windows 7 glitch as you stated it works with Windows 10 using a VM.
@MaxXor commented on GitHub (Nov 2, 2018):
Oh crap, a Windows7-only bug in the .NET Framework... I'll try to check it and find a work-around.
@MaxXor commented on GitHub (Nov 2, 2018):
@mystyq @cyclo-techtwister Could you try removing the
SslProtocols.Tlsin these two lines, recompile and check again? I'll try to get my Windows 7 VM up and running asap in the next few days.github.com/quasar/QuasarRAT@e24b024554/Quasar.Client/Networking/Client.cs (L310)github.com/quasar/QuasarRAT@e24b024554/Quasar.Server/Networking/Server.cs (L283)@mystyq commented on GitHub (Nov 2, 2018):
@MaxXor No luck with
SslProtocols.Noneflag.@cyclo-techtwister commented on GitHub (Nov 2, 2018):
@MaxXor Yea same here made those changes and still behaves the same. Client won't attempt to connect if server is listening.
@MaxXor commented on GitHub (Nov 3, 2018):
@mystyq I didn't mean changing it to
SslProtocols.Nonebut removing that parameter entirely.@cyclo-techtwister commented on GitHub (Nov 3, 2018):
@MaxXor I did changed from "_stream.AuthenticateAsClient(ip.ToString(), col, SslProtocols.Tls, false);"
changed to "_stream.AuthenticateAsClient(ip.ToString(), col, false);"
still same issue..
@MaxXor commented on GitHub (Nov 3, 2018):
Thanks both of you @cyclo-techtwister and @mystyq for testing and helping to figure this out.
Now after debugging this on a Windows 7 VM I can fully reproduce it, the problem are the client certificates it seems...
@cyclo-techtwister commented on GitHub (Nov 3, 2018):
@MaxXor You're welcome and thank you...
@mystyq commented on GitHub (Nov 3, 2018):
Here is some information about SslStream I found on the web.
Link: https://www.winsocketdotnetworkprogramming.com/managediostreamreaderwriter2h.html
Excerpt:
Solution: (Windows 7)
Import the certificate manually into the "Trusted Root Certification Authorities" certificate store (on the machine hosting the server).
@cyclo-techtwister commented on GitHub (Nov 3, 2018):
@mystyq Tried importing and still unable to connect using VM or even a loop back. However the client does attempt to connect but never does. Is it working for you?
@mystyq commented on GitHub (Nov 3, 2018):
It's working for me. I used
mmcto create a snap-in for certificates, then imported the certificate underTrusted Root Certification Authorities.@cyclo-techtwister commented on GitHub (Nov 3, 2018):
@mystyq how would I do the same? mmc create snap-in?
never mind I see what you did.. Yes it works for myself as well. Thanks for this temp work around.
@MaxXor commented on GitHub (Nov 3, 2018):
Thanks for searching @mystyq but thats probably not a solution for me, I would like to leave the certificate storage of the system unmodified and handle it all in memory only.
@cyclo-techtwister commented on GitHub (Nov 3, 2018):
@MaxXor I used @mystyq work around for now (working) but, thank you for continuing to find a built in solution.
@mystyq commented on GitHub (Nov 4, 2018):
I wonder if there is something that can be done in the framework to resolve this... It's strange that Windows 10 allows the certificate to be retrieved from outside of the store and authenticated, where Windows 7 seems to require a CA cert stored in the registry.
@cyclo-techtwister commented on GitHub (Nov 4, 2018):
@mystyq Windows 7 only has about a year and a half left for security update support (Microsoft ended mainstream support for Windows 7 on January 13, 2015, but extended support won’t end until January 14, 2020.) at which time once again all will be forced to upgrade. The question is, is it worth the time and effort modifying the code which may add more bugs that don't exist at this time? After all a System Admin running the server can easily import the cert. and the client runs just fine on outside machine. Just a thought.
@MaxXor commented on GitHub (Nov 4, 2018):
The market share for Windows 7 is still ~40% so it's definitely worth the time and effort, it's not even a big problem. I'll just remove the client certificates to resolve this issue. They were just a nice gimmick anyways.
@MaxXor commented on GitHub (Nov 4, 2018):
github.com/quasar/QuasarRAT@a7dc36ae18This works fine for me on Windows 7 and 10. It provides almost the same security, the client and server gets both authenticated during the connection handshake.
@cyclo-techtwister commented on GitHub (Nov 4, 2018):
@MaxXor OK, sounds good.. It gives people another option. I don't mind importing a cert. I can always remove which is quicker then editing the code and leave better security intact.