I am using SharpPCap to filter packets. Does anyone know how to detect if a packet is for a secured http connection?
You would have to sniff the traffic from the start of the TCP session to observe the SSL handshake go back and forth. Once the encrypted session is set up, any individual packet is going to be indistinguishable from random noise.
To discover otherwise is to find a major flaw in the symmetric cipher. (Yes, the encryption really is that good.)
Of course, having a destination of port 443 is a hint that you are looking at an https connection... But that is just a convention.
Related
As my knowledge, in normal behavior, client will make random port to connect the SNMP service port, now the client use SNMP trap port (162) to communicate with server.
My questions:
As the client setting, I do not have configure any SNMP setting for the client, why WireShark able to capture SNMP traffic came from the client?
Why the client use SNMP trap port (162) to communicate with server, rather than using random port?
SNMP is usually transmitted over UDP, so there is actually no "connection", and speaking technically the source port doesn't matter. You can just send out datagrams (e.g. traps) without binding to a port.
However, even when run over UDP, SNMP does involve some two-way communication. If you are expecting a response (which a client does if it's sending an SNMP Get or Set request), the only place the other end knows to send it is back where the request came from, i.e. the original IP/port combination. There's no information in a SNMP packet that provides any alternative "return address" information.
So, in order to get a response on a predictable port, you'll send the request datagram from a bound socket. Typically the client will run its own listening "server" on port 162, send requests from there, and then it can receive responses there too. Otherwise you wouldn't see the responses. This also allows us to set up simple firewall rules (though you can often get away without firewall rules for the return path, due to hole punching*).
This is also true for the server, which emits traps and informs on a known, standard, predictable port not only so that you can configure your trap receiver and firewalls in a reliable way, but so that inform responses can be sent back to a known, standard, predictable port that you're listening on.
tl;dr: You can send your requests from an arbitrary port if you like, but it's not very useful.
* My SNMP implementation seemed buggy when the client/receiver only saw traps emitted during the ~15 minutes after it had last poked out some kind of request packet. Subsequent traps seemed to be completely missing. After much debugging on the server end, it turned out that we'd forgotten to open the correct port on the inbound firewall for the client, and were accidentally relying on hole punching, which has a time limit. :D
As for why Wireshark is seeing traffic from an unconfigured SNMP client, well, either your SNMP client actually is configured to send requests, or you're misinterpreting the results. Wireshark doesn't invent traffic. Without a more complete picture of your network setup, software setup, and those packets you're seeing, we could only speculate as to the exact cause of your confusion.
I am trying to capture an old application that didn't honour the system's proxy setting. The only config I can change is the server IP address.
Capturing the packets with Wireshark. Without the Charles reverse proxy, I can see requests after the first three handshake requests.
With the reverse proxy, the connection stuck after the handshake requests.
I notice that when Charles received a request and connecting to somewhere but it will just stuck there:
Following is the config of the reverse proxy (Remote host removed):
Any help, solution and workarounds would be appreciated!
First of all, your app uses neither HTTP nor HTTPS. Studying screen shot of successful connection gives some details on protocol used:
the first message after handhsake is originated by server contrary to common client-server approach, where client is responsible for sending query. This fact is enough to cross out HTTP and HTTPS.
payload data isn't human-readable, so it's a binary protocol.
based on PUSH flags, protocol is much more likely to be message-based rather than stream-based
So client establishes connection, immediately gets some command from server and replies it. Then communication continues. I can't guess exact protocol. Port number might be irrelevant, but even if it's not, there are only few protocols using 4321 port by default. Anyway, it can always be custom private protocol.
I'm not familiar with Charles, but forwarding arbitrary TCP stream is probably covered by its port forwarding feature rather than reverse proxy. However, I don't really see any benefits in sending traffic through Charles in this case, capturing data on your PC should be enough to study details.
If you are looking for traffic manipulation, for arbitrary TCP stream it's not an easy task, but it must be possible. I'm not aware of suitable tools, quick googling shows lots of utils, but some of them looks applicable to text based stream only, so deeper study is required.
Reason for Failure
It may be because you are requesting a local IP address from a remote scope, which Charles proxy doesn't applies. For POS(Proof Of Statement), please refer to the below link
https://www.charlesproxy.com/documentation/faqs/localhost-traffic-doesnt-appear-in-charles/
Solution
So In order to solve the problem for the current scenario, use
http://192.168.86.22.charlesproxy.com/
Note: The url that you request will only be proxied properly by Charles not any other proxy services.
is it possible to figure out, or be notified if a peer to whom you are connected is using TCP keepalives?
Furthermore to be notified when a keepalive is sent?
Without resorting to packet-level filtering in a kernel driver?
We have a plug proxy, and a customer wishes client keepalives to be forwarded to the server. At the moment our best option I think is just to allow setting keepalives on the server-side connection, but I wanted to check if anyone knew a way to detect what the client behaviour was so that relaying of keepalives could be more closely approximated.
Thanks.
it possible to figure out, or be notified if a peer to whom you are connected is using TCP keepalives?
No. TCP keepalive doesn't use a protocol extension. It just uses the existing protocol in a specific way so as to provoke a response.
Furthermore to be notified when a keepalive is sent?
No. A TCP keepalive segment cannot be identified as such.
Without resorting to packet-level filtering in a kernel driver?
Not even if you do.
We have a plug proxy, and a customer wishes client keepalives to be forwarded to the server.
Your customer is misinformed.
At the moment our best option I think is just to allow setting keepalives on the server-side connection
Correct.
but I wanted to check if anyone knew a way to detect what the client behaviour was so that relaying of keepalives could be more closely approximated.
Not possible.
I write a HTTP small server under Windows. Access to the server is secured with the usual HTTP auth mechanisms (I use Windows HTTP API). But I want to have no auth for localhost, i.e. local users should be able to access the server without password.
The question is: is that save? More precisely, is it safe to trust the remote address of a TCP connection without further auth?
Assume for a moment that an adversary (Charly) is trying to send a single malicious HTTP GET to my server. Furthermore, assume that all Windows/router firewalls ingress checks for localhost addresses let source addresses of 127.0.0.1 and [::1] pass.
So the remote address could be spoofed, but for a TCP connection we need a full three-way handshake. Thus, a SYN-ACK is sent by Windows upon reception of the SYN. This SYN-ACK goes nowhere, but Charly might just send an ACK shortly afterwards. This ACK would be accepted if the ack'ed SEQ of the SYN-ACK was correct. Afterwards, Charly can send the malicious payload since he knows the correct TCP SEQ and ACK numbers.
So all security hinges on the unpredicability of Windows' TCP outgoing initial sequence number (ISN). I'm not sure how secure that is, how hard it is to predict next session's ISN.
Any insight is appreciated.
In the scenario you are describing an attacker wouldn't get any packets from your web server. If you can use something like digest auth (where a server sends to a client a short random nonce string first and then clients uses that nonce to create an authentication hash) you'd be fine.
If installing a firewall on a system is an option, you could use a simple rule like "don't accept packets with source ip 127.0.0.1 from any interface other then loopback".
I am beginner to free switch.I have gone through the configuration file vars.xml in free switch.
In this I have seen the following configurations.
<X-PRE-PROCESS cmd="set" data="internal_auth_calls=true"/>
<X-PRE-PROCESS cmd="set" data="internal_sip_port=5070"/>
<X-PRE-PROCESS cmd="set" data="internal_tls_port=5071"/>
<X-PRE-PROCESS cmd="set" data="internal_ssl_enable=false"/>
<X-PRE-PROCESS cmd="set" data="internal_ssl_dir=$${base_dir}/conf/ssl"/>
In the above I am having the doubt with tls_port.
What is the use of tls_port .I have searched about this in net and I have read that tls protocol is used for secure data transfer in network.
So please explain me about the communication in freeswitch.
Thanks in advance.
Secure Sockets Layer (SSL) and Transport Layer Security (TLS) are two cryptographic protocols which permits to communicate safely and guarantee data integrity over TCP/IP networks, as Internet for example.
TLS e SSL cypher communication end-to-end at transport layer. Other well known protocols as TCP, UDP enable communication at the same layer.
So as TCP uses port 80 by defualt for communication, you must set a port for your TSL protocol in free switch. This is the meaning of tsl_port parameter previously.
Please keep in mind that TLS is disabled by default, set internal_ssl_enable and/or external_ssl_enable to "true" to enable.
if you don't know what TLS is, you just don't need it in freeswitch.
Freeswitch uses TLS to secure the SIP protocol, but SIP will usually work in clear without encryption and often it's also easier to debug SIP with tools such as wireshark without TLS.
Here you can find further information:
http://wiki.freeswitch.org/wiki/Tls#TLS.2C_SSL_and_SRTP_Encryption
In my view it's better if you don't bother with TLS and Secure RTP as long as you are just scratching the surface of FreeSWITCH, there are more interest things to learn first in my view.
Otherwise if you are on a production environment with very strict security requirements you should study not only FreeSWITCH but the relevant RFCs too! ;-)
I have read that Freeswitch has some mailing capability and many mail-server like gmail or yahoo requires the sending client to have TLS connection with them.