I've found the question but I'm currently using a Trojan server. It didn't come with Username or host IP. It has only the server address, password and port. So the following grammer
import requests
resp = requests.get('http://go.to',
proxies=dict(http='socks5://user:pass#host:port',
https='socks5://user:pass#host:port'))
won't work for me. Is there a similar code for trojan server? Or is there a way for trojan configurations to fit in the code above?
Also, do I have to (or shouldn't) connect to the proxy client if I'm using the proxies in python code? Or should I put it in PAC mode or something?
There's a ":" in the password, so I assume it could fit in the 'user:pass' part but it didn't. (sorry for how stupid it may sound) But the problem may also caused by the conflict of the client.
Related
I'm going to be using gRPC for a device to device connection over a network (my device will be running Linux and collecting patient data from various monitors, gRPC will be used by a Windows client system to grab and display that data).
I obviously want to encrypt the data on the wire, but dealing with certificates is going to be a problem for various reasons. I can easily have the server not ask for the client cert, but so far I've been unable to find a way around the client validating the server's cert.
I've got several reasons I don't want to bother with a server cert:
The data collection device (the gRPC server) is going to be assigned an IP and name via DHCP in most cases. Which means that when that name changes (at install time, or when they move the device to a different part of the hospital), I have to automatically fixup the certs. Other than shipping a self-signed CA cert and key with the device, I don't know how to do that.
There are situations where we're going to want to point client to server via IP, not name. Given that gRPC can't do a cert for an IP (https://github.com/grpc/grpc/issues/2691), this becomes a configuration that we can't support without doing something to give a name to a thing we only have an IP for (hosts file on the Windows client?). Given the realities of operating in a hospital IT environment, NOT supporting use of IPs instead of names is NOT an option.
Is there some simple way to accommodate this situation? I'm far from an expert on any of this, so it's entirely possible I've missed something very basic.
Is there some simple way to set the name that the client uses to check the server to be different than the name it uses to connect to the server? That way I could just set a fixed name, use that all the time and be fine.
Is there some way to get a gRPC client to not check the server certificate? (I already have the server setup to ignore the client cert).
Is there some other way to get gRPC to encrypt the connection?
I could conceivably set things up to have the client open an ssh tunnel to the server and then run an insecure gRPC connection across that tunnel, but obviously adding another layer to opening the connection is a pain in the neck, and I'm not at all sure how comfortable the client team is going to be with that.
Thanks for raising this question! Please see my inline replies below:
I obviously want to encrypt the data on the wire, but dealing with
certificates is going to be a problem for various reasons. I can
easily have the server not ask for the client cert, but so far I've
been unable to find a way around the client validating the server's
cert.
There are actually two types of checks happening on the client side: certificate check and the hostname verification check. The former checks the server certificate, to make sure it is trusted by the client; the latter checks the target name with server's identity on the peer certificate. It seems you are suffering with the latter - just want to make sure because you will need to get both of these checks right on the client side, in order to establish a good connection.
The data collection device (the gRPC server) is going to be assigned
an IP and name via DHCP in most cases. Which means that when that name
changes (at install time, or when they move the device to a different
part of the hospital), I have to automatically fixup the certs. Other
than shipping a self-signed CA cert and key with the device, I don't
know how to do that.
There are situations where we're going to want to point client to
server via IP, not name. Given that gRPC can't do a cert for an IP
(https://github.com/grpc/grpc/issues/2691), this becomes a
configuration that we can't support without doing something to give a
name to a thing we only have an IP for (hosts file on the Windows
client?). Given the realities of operating in a hospital IT
environment, NOT supporting use of IPs instead of names is NOT an
option.
gRPC supports IP address(it is also mentioned in the last comment of the issue you brought up). You will have to put your IP address in the SAN field of server's certificate, instead of the CN field. It's true that it will be a problem if your IP will change dynamically - that's why we need DNS domain name, and set up the PKI infrastructure. If that's a bit heavy amount of work for your team, see below :)
Is there some simple way to accommodate this situation? I'm far from
an expert on any of this, so it's entirely possible I've missed
something very basic.
Is there some simple way to set the name that the client uses to check
the server to be different than the name it uses to connect to the
server? That way I could just set a fixed name, use that all the time
and be fine.
You can directly use IP address to connect, and override the target name in the channel args. Note that the overridden name should match the certificate sent from the server. Depending on which credential type you use, it could be slightly different. I suggest you read this question.
Is there some way to get a gRPC client to not check the server
certificate? (I already have the server setup to ignore the client
cert).
Is there some other way to get gRPC to encrypt the connection?
Note that: Even if you don't use any certificate on the wire, if you are sure the correct credential type(either SSL or TLS) is used, then the data on the wire is encrypted. Certificate helps you to make sure the endpoint to which you are connecting is verified. Failing to use certificates will leave your application to Man-In-The-Middle attacks. Hope this can help you better understand the goals and make the right judgement for your team.
I built a simple Webserver with just the serve function from the std http module. It just redirects a request to a new URL:
import { serve } from "https://deno.land/std#0.120.0/http/server.ts";
serve(req => Response.redirect("https://google.com"))
It works, when I access the server through a browser on my laptop, where the server is running, but when I try to access it on another machine in the same network using the ip-address of my laptop, there simply is no response at all. Is this one of the security features Deno has and if so, how can you deactivate it?
Update:
So I tried looking up the requests I make on my local machine in Wireshark, but when I run the server and send a request, it doesn't show up there. I disabled my Wifi Connection to see if that changes anything and to my surprise, I still got an answer from the server when I sent a request through the browser. I came to the conclusion that the Deno server somehow doesn't serve over the local network which really confuses me. Is there a way to change that behaviour?
This is not related to Deno, but rather the firewall features of your device/router/network or an error in the method that you are using to connect from the other device (typo, network configuration, etc.).
Without additional configuration (by default), serve binds to 0.0.0.0:8000, so — as an example — if your laptop is assigned the local address 192.168.0.100 by your router, you could reach the server at the address http://192.168.0.100:8000.
You might want to do research on SE/NetworkEngineering and elsewhere to determine the cause of the blocked connection.
I apologize for question banality but I have been getting to programming just recently.
I tried to import data from the following website by using the following command on Mathematica:
Import["https://www.soccerstats.com
/results.asp?league=england_2019","Data"]
and this error happens:
ExternalServiceSecuritySetSSLProperties::tsfail: SSL truststore failure: Could not create default trust store.
FetchURL::conopen: The connection to URL https://www.soccerstats.com/results.asp?league=england_2019 cannot be opened. If the URL is correct, you might need to configure your firewall program, or you might need to set a proxy in the Internet connectivity tab of the Preferences dialog (or by calling SetInternetProxy). For HTTPS connections, you might need to inspect the authenticity of the server's SSL certificate and choose to accept it.
It seems related to "https" website protocol, because by trying with any "http" kind the command works.
Any solution to bypass it in order of obtaining data?
How do I get around this error
**The Requested FTP command is not supported when using HTTP Proxy**
occur on the following code
ftpWebRequest.Method = WebRequestMethods.Ftp.DeleteFile.
It is urgent. Can anyone give suggestions for this problem
Your proxy might be blocking FTP delete keywords when filtering requests.
Can you check if you are able to do this activity when not in the proxy (try from a different network where you connect directly).
if yes, i dont think it is straighforward for you to do this activity from behind proxy.
Another solution is to try open source ftps libraries http://ftps.codeplex.com/
or
1. Create a WCF service on the FTP server which allows you to do all that you want.
2. From client side make call to the WCF service passing the command.
I have an Apache SSL connection available with a C# server that listens to port 843 (i wrote a basic c# server since i don't know how to make Apache respond properly upon a specific request).
When using the Socket object, all seems to be find and the connection gets approved, thus allowing the crossdomain communication, however, when using a SecureSocket object, instead of getting , i get lots of gibberish.
I've been trying to figure out what's going on and assumed it's either:
A. using the connection target private key to encrypt the request.
B. trying to authenticate itself via SSL prior to sending the request.
I've spent the entire week trying to figure out whats going on with no luck so if someone can shed some light regarding the way that the SecureSocket obj deals with crossdomain requests it'll be greatly appreciated.
Also, is there a way to use a normal Socket and somehow get the information?
with regards,
Mike
You need to set up a SSL enabled policy server. Using Apache to get rid of the SSL communication and proxy the the policy server didn't work for me as it complains on a bad method.
I wrote a simple java program SSL enabled using the same certificates that the target server (I haven't tested with a different one, so don't know if it's mandatory) to listen on port 843 and replay with the policy. Now I can communicate with SecureSockets.