We came across a scenario where need to upgrade our servers in partial chunks to support TLS1.2 protocol.
We are not expected to run any network capture tool on our production servers like wireshark , etc because it is harmful, so could you please help me in understanding how exactly our protocol handshakes work in case of multi-tier system.
Suppose, our request response is as follows:
A(Client) <--> B(Web Server) <--> C (SOA Servers) <--> D (Third Party Server)
Let me elaborate each entity:
A (Client) : can have OS from Windows7 to windows 10
B (Web Server) : Windows Server 2012R2
C (SOA Servers) : Windows Server 2012R2 + "SchUseStrongCrypto" is enabled
D (Third Party Server) : Can have OS from Windows Server 2008R2 to Window Server 2012R
I am interested to know is there any dependency of protocol in-between multi-tier communication channel?
How actually will the protocol propagate in the above scenario?
Suppose if TLS1.1 is used in-between A to B then is it possible to use TLS1.2 in-between B to C OR C to D?
Related
I would like to use WebRTC with HTML and Javascript on the client side and then have a server written in
Javascript or even C on my server side. I will be happy to use either a Linux or a Windows Server.
I don't want to use a remote server. I would like to perform the NAT traversal locally on my own server.
I have WebRTC running peer-to-peer without NAT traversal and it is very effective.
It is possible to have WebRTC running and do the NAT traversal myself on the local machine?
For WebRTC an ICE Agent just needs a 3-Tuple on each side (IP/Port/Protocol).
Your C server just needs to publish an address that is reachable by the WebRTC Agent in the browser. You have a couple different choices.
You can use a STUN server and establish a NAT Mapping
You can run your server on a internet routable address, and don't need to worry about mapping
You can do port forwarding. Your server can be in a NAT, but will be world routable on a range of ports
You can use something like NAT-PMP or PCP
ICE (the protocol that WebRTC uses) doesn't care where the candidates come from. It just works on finding a route that works.
Suppose, we have a media server S deployed. We have a client C who is behind a symmetric NAT. The direct WebRTC media streaming is not possible due to symmetric NAT. So we want to deploy a TURN server T, which would relay all media between S and C.
Now, it seems that developers sometime deploy T near S for simplicity. But does it help to stream media between C and S? "Near" means "in the same network", so S and T are behind the same NAT if there is some. Since, they are behind the same NAT, it doesn't seem to improve connectivity: chances to stream WebRTC traffic between S and C are the same as between T and C.
Is this reasoning correct or am I missing something? In my current understanding, TURN servers act like a proxy with better connectivity with respect to C. So they should be placed in another network to make any effect.
C -> T can do a few things that C -> S can't do
DTLS and TLS transport, ICE only allows UDP and TCP. Some gateways only allow TLS on 443
Single port, you can do all traffic on one well know port. Gateway may only allow :443
S may not support ICE-TCP. Some SFUs do support it though!
We have an application running on windows 2012 R2 OS with 4.6 framework and database as SQL server 2012. Due to security concerns we were asked to enable TLS1.2 protocol for the calls made between application server to database server and vice versa. I have followed below URL and we have all patches installed.
https://support.microsoft.com/en-us/help/3135244/tls-1-2-support-for-microsoft-sql-server.
Our front end application doesnt directly call the database instead we have WCF service in between front end application (asp.net) and SQL server. I read in an article we can achieve this without making changes to the code and change the providername ="SQLNCI11". When i change the provider name like below i am getting error. saying that "Unable to find the requested .Net Framework Data Provider"
Data Source=servername;Initial Catalog=DBname;uid=XXX;pwd=XXXX;Connect Timeout=200;MultipleActiveResultSets=True;Current Language=us_english; providername="SQLNCI11"
I have verified machine.config and i dont find DBproviderfactory for SQL native client.Am i missing anything here?
As an alternative, Without changing provider name in connection string i have added Encrypt=true;TrustServerCertificate=true in connection string
Data Source=servername;Initial Catalog=DBname;uid=XXX;pwd=XXXX;Connect Timeout=200;MultipleActiveResultSets=True;Current Language=us_english; Encrypt=true;TrustServerCertificate=true providername="System.Data.SqlClient"
After making above changes in connection string database call was success and when i see Ethernet communication using wireshark tool, database to WCF service communication is made with TDS protocol and TLS is involved according to wireshark tool. If i remove "Encrypt=true;TrustServerCertificate=true" from connection string then i dont see "TLS Exchange" message.
What steps should I need to take to ensure the application use TLS 1.2 protocol to communicate with the database? and also please suggest how to prove this communication.
One year later, I wanted to assess the same thing - knowing exactly what TLS version is in use for my MS SQL traffic.
Actually TLS is encapsulated in TDS when it comes to MS SQL traffic.
You can see TDS header (starting by 0x12 - higlighted in yellow in the picture).
After this header begins the TLS packets and you can check version by looking at 2nd and 3rd TLS packets.
In my example, 0x03 0x03 stands for TLS 1.2 (3rd version of TLS protocol)
There are two servers:
Local Server
behind a firewall (DSL Router)
connected to microcontrollers (actors & sensors)
Cloud Server
sends commands to Local Servers
The idea is that the Cloud Server sends commands to the Local Server. E.g. to trigger an actor. If there was no firewall, the best way would be IMHO to have a REST API on the Local Server. Unfortunately configuring a NAT is not an option.
What is the simplest and most common way to solve this?
Your other options are:
a) pulling, webrequest from local to online server.
b) service bus, also a pulling pattern but with a queue (i.e. Azure Service Bus or Event Hub in example)
c) server of manufactor, sometimes there is already a online service ready, like meethue-API for the hue Philips IoT Lamps
Let me know if you need more hint's.
Frank
So, we all use TeamViewer for accessing GUI based (Windows / Linux) remotely and of course, it works really well.
Any ideas of how to do the same with headless (Ubuntu) servers? I'm thinking that the headless servers would run some sort of service that connects to a central server, which I can then remote into (somehow) and then route through the central server to the remote server.
It's kinda like the server based TightVNC that was popular a view years ago, where you could host the "server" module and have all your TightVNC clients connect to that server, whilst you do the same on your client, and the server module provides a gateway through to the remote systems. Just like TeamViewer really.
I wonder if the remote servers can connect to the (central) gateway server via SSH, I would do the same (again via SSH) but then the gateway server will provide me a "tunnel" through to the remote server.
I would of course prefer to have the remote servers have SSH ports opened through their firewall and then connect to them directly, but sometimes their IT teams don't like that. Having a server that runs a service, connects to a public server, means that the IT team will typically permit this, as the traffic is initiated internally and would be even more so agreeable to permitting it if that traffic uses an encrypted protocol.
Anyway - I just wondered if there was something out there that I could have a look at and see if it would work??
If you don't want a cloud controlled service (with serious security issues as of late), then check out the self-hostable MeshCentral project. It creates outbound tunnels that allow devices to communicate behind NAT and other networks.
Good news! Teamviewer 11 supports headless Linux servers :)
https://www.teamviewer.com/en/help/1111-How-do-I-install-TeamViewer-on-a-Linux-system-with-no-graphical-user-interface
Try https://www.dwservice.net/en/
Works on RPI, Linux and Windows.Best Part is free and Support for Terminal access
not just GUI ( so works faster in slower internet ) .
Client side- > just run the script ( not need of GUI)
Remote side - > Run just browser.