I would like to use tailscale to access my nas browser interface from anywhere. I read here that tailscale encrypts all traffic fully at the IP level, before it leaves the device.
Does this mean I can securely enter my login data, even though the nas browser interface has only a http connection (with a tailscale ip)?
Tailscale encrypts all traffic at the IP layer. If you connect to the Tailscale IP address, the traffic is carried securely to that node.
If you want to additionally hook up HTTPS, there is support to help get certificates issued for your node: https://tailscale.com/blog/tls-certs/
Related
Is it possible to give a application load balancer on AWS a SSL certificate, allowing allowing only HTTPS connections, if I don't want to use a custom domain?
Currently developing some internal dashboard applications, so have no need/want for a domain name attached to them.
I can only dig up info and tutorials of creating to a certificate in Cloudformation, when wanting to add a domain forwarding to the LB.
The SSL certificate has to have a valid DNS name associated with it in order to work. You need to request a certificate via ACM and then attach that to the ELB. You can configure the ELB to only have an HTTPS listener to force secure communication.
Probably not.
It's not generally kosher to issue an SSL certificate to an IP address, and since all *.compute.amazonaws.com style DNS names are floating and could be reassigned at any moment, they damn well won't issue one for them either. (Same stands for Let's Encrypt, by the way: you have to have a DNS name not issued by a provider.)
Just give your internal service a DNS name, be it something like mydashboard.internal.mycompany.com or whatever; it'll be easier to access, too.
I am creating a voice-bot using dialogflow with google assistant. My client has provided his network access, which is not a private URL an IP instead. It is not SSL certified too. I will get two errors this time
Only public URLs are allowed and
You can use only https:// in fulfillment url when "Google Assistant" integration enabled
Any workaround for this? What are the other options I have? I can access clients API within his network only. So I cannot replace this IP address. Please advise how to proceed further.
You can use an IP address, as long as it is a public IP address. The machine doesn't need a DNS entry.
Actions on Google requires an HTTPS connection, however, using a valid certificate (ie - not self-signed). This is to protect your client and their users data.
One possible workaround is to look into a tunnel/proxy service such as ngrok. They provide a public HTTPS address that securely tunnels to an ngrok client you run on the same machine as the webhook fulfillment server. They have a free service that will change hostnames periodically, or you can subscribe to a commercial service which will give you a fixed name which you can use for the fulfillment URL.
You have to make URL https://.
you can try https://letsencrypt.org/
I have a gadget[*] that connects to the user's WiFi network and responds to commands over a simple REST interface. The user uses a web app to control this gadget. The web app is currently served over http and the app's javascript does AJAX calls to the gadget's local IP address to control it. This scheme works well and I have no issues with it.
[*] By "gadget" I mean an actual, physical IoT device that the user buys and installs within their home, and configures to connect to their home WiFi network
Now, I want to serve this web app over https. I have no issue setting up https on the hosting side. The problem is, now the browser blocks access to the gadget (since the gadget's REST API is over http and not https).
The obvious solution is to have the gadget serve it's REST API over https. But how? It has a local IP address and no one will issue a certificate for it. (Even if they did, I'd have to buy a boatload of certificates for each possible local IP address.) I could round-trip via the cloud (by adding additional logic on my server side to accept commands from the web app and forward it to the gadget over another connection), but this will increase latencies.
Is there a way around this problem? One possibility that I have in mind is to:
Get a wildcard certificate (say, *.mydomain.com)
Run my own DNS that maps sub-domains to a local IP address following a pattern (For example, 192-168-1-123.mydomain.com would map to 192.168.1.123)
Use the wild-card certificate in all the gadgets
My web app could then make AJAX calls to https://192-168-1-123.mydomain.com instead of http://192.168.1.123 and latencies would remain unaffected aside from the initial DNS lookup
Would this work? It's an expensive experiment to try out (wildcard certificates cost ~$200) and running a DNS server seems like a lot of work. Plus I find myself under-qualified to think through the security implications.
Perhaps there's already a service out there that solves this problem?
While this is a pretty old question, it is still nothing that you find out-of-the-box solutions for today.
Just as #Jaffa-the-cake posted in a comment, you can lean on how Plex did it, which Filippo Valsorda explained in his blog:
https://blog.filippo.io/how-plex-is-doing-https-for-all-its-users/
This is very similar to what you proposed yourself. You don't even need a wildcard certificate, but you can generate certificates on-the-fly using Let's Encrypt. (You can still use wildcard certificates, if you want, which Let's Encrypt supports now, too.)
Just yesterday I did a manual proof-of-concept for that workflow, that can be automated with the following steps:
Write a Web Service that can create DNS entries for individual devices dynamically and generate matching certificates via Let's Encrypt - this is pretty easy using certbot and e.g. Google Cloud DNS. I guess Azure, AWS and others have similar offerings, too. When you use certbot's DNS plugins, you don't even need to have an actual web server running on port 80/443.
On you local device, contact that Web Service to generate a unique DNS entry (e.g. ..yourdns.com) and certificate for that domain
Use that certificate in your local HTTPS server
Browse to that domain instead of your local IP
Now you will have a HTTPS connection to your local server, using a local IP, but a publicly resolved DNS entry.
The downside is that this does not work offline from arbitrary clients. And you need to think of a good security concept to create trust between the client that requests a DNS and certificate, and your web service that will generate those.
BTW, do you mind sharing what kind of gadget it is that you are building?
If all you want is to access the device APIs through the web browser, A Simple solution would be to proxy all the requests to the device through your web server.this was even self signed certs for the devices wont be a problem. Only problem though is that the server would have to be on the same network as your devices.
If you are not on the same network, you can write a simple browser plugin (chrome) to send the api request to IoT device. but then the dependency on the app/plugin will be clumsy.
I'm trying to add security to my remote actors. I've set untrusted-mode:
http://doc.akka.io/docs/akka/snapshot/scala/remoting.html
Is it possible to add IP filtering, to allow connection only from specific server? For example I have one master and 10 slaves, I want to allow only for my master (specific IP) to connect my slaves.
In open source everyone could just create a new instance of my master, and connect to my real slaves. How can make it secure?
Using IP filtering is not very secure as it's easy to fake an IP. Luckily Akka comes with secure transport support via SSL and secure cookie support.
A cookie is like an API key and will be required to establish the connection. SSL will guarantee eavesdropping is not possible to steal the secure cookie. See this doc for example.
I made a simple project that uses Akka remoting and SSL with secure cookie. Try it out here. Read how to setup SSL certificate storage and such here.
I am going to use Secure Gateway service in Bluemix and I have some questions about how I should make it work.
Systems in my data center's intranet access the Internet through a proxy (with no authentication). Can Secure Gateway connect to Bluemix via a proxy?
Does it connect to Bluemix via HTTPS protocol?
The network admins asked me: What are the IPs (or the IP range) of Bluemix, any idea?
Thank you very much.
A Secure Gateway instance runs in two parts, as shown in "Reaching enterprise backend with Bluemix Secure Gateway via console": the gateway and the gateway client. The gateway runs in Bluemix, the gateway client runs in the data center containing one or more systems of record to connect to. The gateway client needs network access to the Bluemix data center (typically via the Internet) and to the systems of record (via the data center's internal network). The gateway client initiates the connection, so it needs to know Bluemix's address, but Bluemix doesn't need to know the gateway client's address.
To answer your questions specifically:
A proxy isn't supported. The gateway and its client need direct access to each other.
The connection uses HTTPS for SSL encryption. The transport level security (TLS) options can be used to add authentication.
Bluemix's IP addresses aren't published.
For point 3:
The client connects outbound to the cloud services. Once the SecGW is connected, all additional Destination connects flow through that connection, no additional firewall or iptables rules are needed. If they have a rule in-place so that the on-premises machine where the SecureGateway client is installed can use the outbound port 443 (HTTPS) to make connections, that is all they need.