We have an engaged (but friendly) discussion between coworkers about the life time of the SSL session underlying a https communication.
When I establish a https connection to a server using a normal browser the underlying ssl creates a session (including a shared secret) using asymmetric encryption, the rest of the communication is encrypted using (faster) symmetric encryption.
The question is: On a subsequent https requests (click on a link) to the same server, is the old ssl session used again, avoiding the overhead of the asymmetric encryption for establishing a session key? Or is a new asymmetric encrypted ssl handshake for establishing a ssl session necessary?
Or to word it differently: Does a SSL session stays alive between https requests, or does it end with the end of the https request?
Since we are a bunch of nitpicks over here a reference to some authorative source would be apreciated.
Tested this out with Chrome:
navigate to https://www.americanexpress.com. netstat shows:
$ netstat -n -p tcp|grep 184.86.149.155
tcp4 0 0 10.177.78.58.50311 184.86.149.155.443 ESTABLISHED
tcp4 0 0 10.177.78.58.50310 184.86.149.155.443 ESTABLISHED
tcp4 0 0 10.177.78.58.50309 184.86.149.155.443 ESTABLISHED
On navigating to other links on the website, netstat shows:
$ netstat -n -p tcp|grep 184.86.149.155
tcp4 0 0 10.177.78.58.50311 184.86.149.155.443 ESTABLISHED
tcp4 0 0 10.177.78.58.50310 184.86.149.155.443 ESTABLISHED
tcp4 0 0 10.177.78.58.50309 184.86.149.155.443 ESTABLISHED
The session was kept alive. When I closed the browser tab, and re-opened the tab, another connection was opened:
$ netstat -n -p tcp|grep 184.86.149.155
tcp4 0 0 10.177.78.58.50398 184.86.149.155.443 ESTABLISHED
tcp4 0 0 10.177.78.58.50311 184.86.149.155.443 ESTABLISHED
tcp4 0 0 10.177.78.58.50310 184.86.149.155.443 ESTABLISHED
tcp4 0 0 10.177.78.58.50309 184.86.149.155.443 ESTABLISHED
It would appear that modern browsers utilize the same keep-alive timeouts as http. These timeouts can be viewed here:
http://gabenell.blogspot.com/2010/11/connection-keep-alive-timeouts-for.html
See section 2.2 of http://www.ietf.org/rfc/rfc2818.txt and section 8.1 of http://www.ietf.org/rfc/rfc2616.txt
In essence, the SSL session SHOULD be maintained while the client maintains a persistent connection.
For more information about the implementation of persistent connections in popular browsers see http://en.wikipedia.org/wiki/HTTP_persistent_connection#Use_in_web_browsers
If your browser supports session resuming and the server has cached the session, then you may be able to continue a session between connections, GNUTLS supports this and you can see a demo here:
https://test.gnutls.org:5556/
Related
I am new to Websockets, and I have the following setup (below). What I am trying to determine is whether or not the communication taking place from Apache back to the browser is truly secure.
I am initiating a WebSocket connection through wss:// (port 443) from the browser to Apache. Through mod_proxy_wstunnel, I connect to Ratchet over a non-secure ws:// connection on port 8080.
When Ratchet sends back a data frame over the non-secure port 8080, will mod_proxy_wstunnel encrypt the data so that Apache sends it back to the browser encrypted?
|---------| 443 |--------------| |--------------------| 8080 |---------|
| Browser | <---> | Apache httpd | <-> | mod_proxy_wstunnel | <----> | Ratchet |
|---------| |--------------| |--------------------| |---------|
I know that the initial connection is done via HTTPS on port 443 and switches protocols through a WebSocket handshake. But according to https://www.websocket.org/aboutwebsocket.html after the protocol switches, "the HTTP connection breaks down and is replaced by the WebSocket connection over the same underlying TCP/IP connection. The WebSocket connection uses the same ports as HTTP (80) and HTTPS (443), by default."
Just because it is communicating on the same port, doesn't necessarily mean to me that it is still truly encrypted, especially when the HTTP connection "breaks down." It looks to me in this instance that mod_proxy_wstunnel is simply forwarding on the data as-is from Ratchet, and as such the data is being passed un-secured over port 443, giving a false sense of security.
I have exactly the same setup except I use Crossbar IO in the backend instead of Ratchet.
I used Wireshark to investigate the packets of both secured and unsecured connections. I could easily read the data of the unsecured connections (as you would expect). When I switched to secured, Wireshark didn't even recognize that the websocket protocol was used and I couldn't see anything resembling my data.
From this I conclude that mod_proxy_wstunnel encrypts the data it sends back to the browser as you would hope.
Ive searched internet but didnt got the answer can any1 explain me the difference between them
A TCP "connection" is a 4-tuple. Local IP, Local Port, Remote IP, and Remote Port. Each end maintains this identification within its TCP stack, with the senses reversed (Local vs. Remote).
The combination of these 4 values must be unique. This explains the problems people often have writing a TCP client that reuses a socket to reconnect to the same server.
A "closed" connection leaves this ID in the tables at each end for some time, in TIME_WAIT state. This is an artifact of a TCP mechansim that deals with maintaining connection integrity even if the physical layer connection breaks, keeps pending packets from being recevied by a second connection, etc. TIME_WAIT can last up to 4 minutes.
Unless the client resets its socket's LocalPort to 0 (which is a request for an automatic ephemeral port assignment) it can fail if it tries to reconnect before TIME_WAIT expires. Since this is 0 for a newly created socket, programmers often overlook this requirement prior to calling Connect.
LocalPort isn't just an issue for listening sockets.
A server listens on a localport, while a client sends data from the localport.
The client remoteport should be the same as the server localport.
i.e.:
Server listens on port n (local port relative to server)
Client connects to server on port n (remote port relative to client)
To answer your question, the difference is in name, based on perspective.
This seems to be a good place to start with VB6 socket communication
I'm running Kamailio SIP server on one server. It works fine with SIP clients etc.
Now I'm trying to run Siproxd SIP Proxy on another server.
I've installed Siproxd and calling netstat -tulpn | grep 5060 shows:
tcp 0 0 0.0.0.0:5060 0.0.0.0:* LISTEN 22216/siproxd
udp 0 0 0.0.0.0:5060 0.0.0.0:* 22216/siproxd
So it is running.
But when I try to connect clients to my original Kamailio SIP server with the server IP from the one running Siproxd as proxy, it fails.
Can anyone help my out debug the problem?
And shouldn't this solution, when it works, make my clients looks as if they come from the IP of the server running Siproxd?
Get familiar with Wireshark.
It looks daunting at first, but especially for text based protocols like SIP or HTTP you'll only ever need to start a capture by clicking on the pseudo-interface "any", do a connection attempt, pick a packet that goes to 5060, right click on that and choose "follow TCP stream".
Tell us how exactly it fails and we'll go from there.
I have got some wireshark captures, and it shows that it is UDP. But in theory it says that it uses both TCP and UDP. So I m confused. And what is the difference b/w LDAP and CLDAP? Are they both UDP protocols?
Normally LDAP is a TCP protocol. But Microsoft uses LDAP also over UDP. See here:
http://msdn.microsoft.com/en-us/library/cc717362(v=prot.10).aspx
So it is both.
Lightweight Directory Access Protocol (LDAP)
The Lightweight Directory Access Protocol: The protocol accessing data from directory services like OpenLDAP, Microsoft Active Directory, Netscape Directory Server or Novell eDirectory.
Protocol dependencies
TCP/UDP: Typically, LDAP uses TCP or UDP (aka CLDAP) as its transport protocol. The well known TCP and UDP port for LDAP traffic is 389.
SSL/TLS: LDAP can also be tunneled through SSL/TLS encrypted connections. The well known TCP port for SSL is 636 while TLS is negotiated within a plain TCP connection on port 389.
https://wiki.wireshark.org/LDAP
I had some networking issues on my Windows server, and find out (by using NETSTAT) that I have more than 90,000 (!) connections in TIME_WAIT which didn't closed.
I've changed the TcpTimedWaitDelay param in registry, but apparently a server restart is needed.
Because it's a single production DB server, I can't afford it at the moment.
Is there any way killing a TIME_WAIT connection?
Any other suggestions?
Thanks!
Roei
I have more than 90,000 (!) connections in TIME_WAIT which didn't closed.
No you don't. These represent connections which have already closed, and whose local port is hanging around for TCP security reasons. They will only be that way for a couple of minutes each. Just wait.