I am trying to view the messages and communication of an SSL WebSocket server and client. The client is written in Java, so I could technically view the code with something like Recaf or JD-GUI, but I do not have access to the WS server. Is there any program that I could use to intercept the traffic of the client and server (Note: I am able to change the host, port, and protocol of the client's WS connection (like change it to ws://localhost:8080 from wss://server:port/path)).
Is there any program that can act as a non SSL WebSocket server, and then forward all connections to the remote server while logging the messages?
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 am unable to connect to socketcluster server from Firefox and chrome for android. Is there any solution?
The 'Socket hung up' error can mean either: The server was disconnected abruptly (e.g. the connection was lost for whatever reason). OR the client could not find the target server while trying to connect - It could be because the wrong arguments were passed to the client (E.g. don't match the server host, port, ...) or a network connection issue.
Are you trying to connect over 3G? Some 3G ISPs and some corporate networks block raw WebSocket traffic. If that's the case, the solution is to serve SocketCluster over wss:// - Proxies won't be able to block it if the connection is encrypted.
To make it work, you just need to provide a TLS key and certificate to the main SocketCluster constructor. Or you can put the raw SC server behind a TLS-enabled load balancer like AWS CloudFront, CloudFlare or similar (make sure it supports proxying WebSocket traffic).
I have a IBM HTTP Web Server setup as a reverse proxy for a WebSphere application server. We use Oracle Access Manager for user authentication. There is also a Oracle Webgate running on the IHS server to intercept the requests and check them against the Oracle policy.
I can see the authentication going through and Oracle passes back the value needed in an HTTP Header, OAM_REMOTE_USER. The problem is, at some point in the process, that header is not passed on to the WebSphere Application Server.
The Oracle Webgate is monitoring port 8443, but I am not understanding if that means for the Web Server or the App Server since both are on the same physical machine and have the same server name. If I just create a virtual host on the Web Server for 8443 and do not create the port on the App Server, the headers are going through correctly. The problem with this is that I have to use PreserveProxyHeader for the request to go through the WebGate 8443 port, so after authentication it comes back looking for my Application on port 8443, which does not exist on the Web Server. The only way it can find my application on port 8443 is if I also add a port on the App server for that port, which contains the application.
I guess the main thing I am struggling to understand is if I need to define the port Webgate monitors on the HTTP Server and App Server, or if it should only be on the HTTP Server side. It seems like no matter what I do, at some point the request gets redirected from the HTTP Server to the App Server and strips out any OAM HTTP headers that were there. I've managed to prevent them from dropping by removing the 8443 port from the app server, but now my app cannot be mapped to.
This is WebSphere App Server 8.0 and IBM HTTP Server 8.0.0.5.
In the administrative console, click Servers > Server Types > Web servers > web_server_name > Plug-in properties > Request routing. Disable "Remove special headers". Regenerate your plugin configuration XML, and redistribute it.
I'm planning on using a wsDualHttpBinding for a WCF service with callbacks. The clients will be a windows form application communicating to the service over the internet. Obviously I have no control over the firewall on the client side, so I'm wondering what is the proper way to set the ClientBaseAddress on the client side?
Right now in my intiial testing I'm running the service and client on the same pc and i am setting the binding as follows
Dim binding As System.ServiceModel.WSDualHttpBinding = Struct.Endpoint.Binding
binding.ClientBaseAddress = New Uri("http://localhost:6667")
But I have a feeling this won't work when deploying over the internet because "localhost" won't translate to the machine address (much less worrying about NAT translation) and that port might be blocked by the clients firewall.
What is the proper way to handle the base address for callbacks to a remote client?
some one tell me if i do not specify ClientBaseAddress then WCF infratructure creates a default client base address at port 80 which is used for the incoming connections from the service. Since port 80 is usually open to firewalls, things should just work.
so just tell me when win form wcf client apps will run then how can i open my custom port like "6667" and also guide me what library or what approach i should use as a result response should come from client side router
to pc and firewall will not block anything. please discuss this issue with real life scenario how people handle this kind of situation in real life. thanks
The proper way is to use TCP transport instead of HTTP transport. Duplex communication over HTTP requires two HTTP connections - one opened from client to server (that's OK) and second opened from server to client. This can work only in scenarios where you have full control over both ends. There is simply too many complications which cannot be avoided just by guessing what address to use like:
Local Windows or third party firewall has to be configured
Permission for application to run - listening on HTTP is not allowed by default unless UAC is turned off or application is running as admin. You must allow listening on the port through netsh or httpcfg (windows XP and 2003) - that again requires admin permissions.
Port can be already used by another application. In case of 80 it can be used by any local web server - for example IIS.
Private networks and network devices - if your client machine is behind the NAT the port forwarding must be configured but what if you have two machines running your application on the same private network? You cannot forward from the same incoming port to two machines.
All these issues can be avoided mostly only when you have control over whole infrastructure. That is the reason why HTTP duplex communication is useful mostly for intranet scenarios and why for example Silverlight offers another implementation where the second connection is not created and Silverlight client instead polls server continuously to check if there is any callback available.
TCP transport requires only single connection from client to server because TCP protocol is natively duplex so the server can call back the client through the same connection. When you deploy a public service you usually have control over infrastructure on the server side so you can make necessary changes in configuration to make it work.
I think this also answers your previous question.
Is it not possible to specify the local client port used for server calls via NetTcpBinding?
NetPeerTcpBinding support this - I find it hard to believe there's no way to specify the local port (and IP Address for that matter) on clients.
I need to be able to use port sharing and I can't do this if I don't know what port the client is listening on. I won't be able to share the port (and IP) with another client so it can connect.
The only work-around I found is something like this:
Client A opens a connection to Server
Server logs the IP and Port of Client A
Server shares this info. with
Client B
Client B should be able to
connect to Client A on specified IP
and Port (in theory)
This is known as TCP/IP NAT hole punching I believe. Anyone with experience in this?
You probably don't understand the communication pattern with NetTcpBinding. It works this way:
The client opens connection to the server
Two-way communication: The client calls the server and gets the response over the same connection.
Duplex communication: The client calls the server. The server stores reference to the channel somewhere (you must implement this). Once the server wants to notify client about anything it takes stored channel and calls the client on the connection established by the client during its first call.
The server never opens connection to the client. The client doesn't expose any address with port for incomming communication. If you want to do that you must implement service on the client in the same way you did it on the server and you must manully send the address and port to the service exposed by the server.
The difference with NetPeerTcpBinding is that there is no real server and any client must be able to get incomming request. NetTcpBinding is for client-server scenarios where the server is the only peer able to process incomming requests. Because of that only the server needs to define an address and a port.