My understanding of long polling is that the server will keep the connection alive until there is some event. If we keep the port open, does it not make it vulnerable to security threats.
Your system has a connection open to the Box server. Your system will not listen for new incoming requests on that port. Your connection is encrypted (HTTPS), so even a man-in-the-middle should not be able to mess with your stream.
As long as your SSL connection is not compromised, you are safe. If your SSL connections are getting compromised, you have bigger problems.
Related
I am developping a FTPS client in a Embedded system with LWIP and mbedTLS stacks.
For now, what I do is :
Get an IP adress with DHCP
Get IP address of the server with DNS
Start a TCP connection to the server ( the control connection)
Telling the FTP server that I want to work with the TLS protocol with the command AUTH TLS
Handshake of the TLS protocol with the server
Validate the x509 certificate that the server sends
Telling the client that I want to work in passive mode and that i want to read a file with the command RETR.
Now, I need to open a data connection to read my file. So what I wanted to know is does the data connection is secured in the same way the control connection is ? That means do I have a certificate to validate ? Is the handshake the same ?
If this isn't clear let me know i'm not an expert at all in this area.
Thank you for your future responses
In explicit FTPS connection after you send AUTH command, the data connection is secured all the way. Depending on Active/Passive connection the data connection is opened through port 20(Active) or some random port negotiated(Passive).
You don't need any extra handshakes as far as I know.
You might or might not be able to configure if you want to reuse the same session ID created in opening the control channel. This is related for server to know that data connection has been established by the same client which opened the control channel. Some server require this, some servers allow this, some servers does not support this.
I'm working on designing a server, in which the protocol allows for the client to open additional physical connections to the server which operate in the context of a single logical connection.
One thought I had was that, if we're using ssl, we'll need to do another ssl handshake for the new connection. It seems to me that it should be possible to send some secret to the client over the original, secure connection that would allow the new connection to be securely established without a handshake (similarly to what I've read about ssl session reuse).
Is this actually possible?
SSL already does this. Provided both ends support it, there is a feature called 'session resumption' which allows a new connection via an existing SSL session, via a much abbreviated handshake, without the certificate exchange and negotiation of shared secrets.
Yes, by reusing SSL Session. You can do this by using PEM_write_bio_SSL_SESSION and PEM_read_bio_SSL_SESSION and then adding it to SSL Context.
Keep in mind you only need to do this in client mode, server mode does this automatically for you.
I have been trying to connect to a partner's web service which is running on HTTPS default port 443. I had been under wrong impression that they had not open firewall ports for us because telnet from my server was unable to establish a connection. For example, I was typing:
$ telnet <vendor's host> 443
After waiting a long time (Around 15-20 seconds), it prints out that it connected but immediately also says that the connection closed:
Connected to <host>.
Escape character is '^]'.
Connection to <host> closed by foreign host.
However, on running the SOAP UI from the server and hitting a URL that is hosted on the same host and port works fine.
Just wondering why telnet connection gets tripped. Is there any kind of setting possible at the server side?
Maybe you're actually making a Telnet connection? But then it closes because the server finds no interesting conversation, because the server is expecting SSL negotiations to complete.
Understand that Telnet is not very different than TCP. ][CyberPillar: Telnet may discuss that.) So what would you expect the SSL server to do with a TCP connection? In the case of an HTTPS server (which is what I'm presuming, since you mentioned TCP port 443), I would expect the HTTPS server to want to immediately perform SSL negotiation. If a client does not successfully provide SSL negotiation, then the client may just be an attacker trying to use up the server's resources. So, the server won't be wasting resources by responding in interesting ways (like printing out an informative message). That would be the behavior that provides the most desirable results, most of the time. Most connections from clients who know what they are doing will be HTTPS connections by a client that does know how to negotiate SSL.
I would expect similar results from many other protocols that are designed to use encryption. Offhand, I don't know that this behavior is absolutely required by any specific technical specifications/requirements. However, what I do know is that the description you provide, which notes the behavior you experienced, is really not surprising to me whatsoever. Perhaps just from some experience I've had, it's what I would expect. The results you describe would not be surprising to me, even if your firewall was doing nothing. Consequently, I don't offhand know whether your firewall is effectively doing anything noteworthy with this traffic. Maybe the firewall is blocking it, or maybe the firewall is passing it to an HTTPS server which is just handling the connection in a way that you weren't expecting.
I am using the google's TURN servers which is given in the demo, Sometimes the connection is established and remote video is streamed sometimes I just get a black screen instead of remote stream. Are these servers not reliable or is there any other issue because I can see the IP of the other machine on the peer which means the peer connection has been established. So what could be the possible problem is?
google doesn't provide any TURN server, only a STUN one.
There's a lot of situation where you need a TURN server, but as far as I know, there's no open TURN server. Even when the ip is detected, you can have problems with a proxy destroying the UDP stream or some of the ports needed.
I thank you in advance for sharing your knowledge. Here is my question:
By default, SQL Azure connections are encrypted. so what is the significance of checking the 'encrypt connection' checkbox in the connection properties while connecting to SQL Azure from SSMS? Does it make any difference?
Paras,
When the client library first attempts a connection to SQL Server / SQL Azure, it sends an initial connection request. Consider this a "pre-pre-connection" request. At this point the client does not know if SSL/Encryption is required and waits an answer from SQL Server/SQL Azure to determine if SSL is indeed required throughout the session (not just the login sequence, the entire connection session). A bit is set on the response indicating so. Then the client library disconnects and reconnects armed with this information.
Consider a proxy sitting between the client and SQL Azure (or SQL Server). The client talks to the proxy, and the proxy talks to SQL Azure/Sql Server. If you do not force the encryption bit on the client, you leave it to the proxy to encrypt or not the session. The proxy could encrypt the connection on the backend (it would have to for SQL Azure) but not on the client-side of the connection, hence accessing all your sensitive data. So checking the encryption box bypasses the "pre-pre-connection" request which prevents any proxy from turning off the encryption bit in question on the client side of the proxy, hence avoiding the man-in-the-middle attack.
Hopefully that makes sense... :) If you download Wireshark and watch what happens with the pre-pre-login packets, you will see what I mean. Checking the box changes the pre-login handshake mechanism to avoid the man-in-the-middle attack I described.