I'm struggling with Netty 4.0.8 Websocket client example and SSL and I can't seem to be able to send data to the Netty SSL websocket server example. Although there have been many posts around this issue, (I went through all, I believe), and the most common suggestion is to just add an sslHandler to the beginning of the pipeline, it doesn't work. Handshake seems to be successful as it is also indicated to a relevant question here.
I remember being in the same situation with version 4.0.0, but I somehow managed to get it working. However, things (and API) changed when I upgraded to 4.0.8.
Can the Netty developers add a working Websocket SSL client example to the examples? Many people struggle with this issue and that would be useful. Maybe the solution is just too simple, but an example would clear things. Again, sorry for reposting a question that might be already there, but the relevant question has also been unanswered and my reputation is just too low to add a comment to other relevant questions :)
I seem to have found a solution to my own question. The sample code on the client uses the channel.write() method, which seems not to send the messages to the Websocket ssl server. By using the channel.writeAndFlush() instead, messages are correctly sent to the server.
Related
I have a SIM800L module. Which has R14.18 firmware(supports TLS 1.0 and SSL) in it. I am having trouble to connect to http"S" servers. I can connect http servers no problem there. All this information and steps i got from datasheets, forums and YouTube videos. But i havent seen anyone connect to http"S" servers specifically.
I have no idea what I am missing if someone could rightdown the steps as a dummies guide that would be great.
Thanks in advance.
P.S: I am planing to use this with arduino iot cloud api any help would be appreciated there!
So far i tried;
Configuring the bearer and http with AT commands always getting 601,603,605 etc.
I checked the DNS and SSL cert but I'm not confident there since these are new to me
Tried to connect with TCP/IP wasn't able to connect.
Ok i figured it out i just needed to be a bit more careful that was all :)
I have successfully written an Akka.net actor that communicates using System.Tcp(), how can I now convert this to use SSL?
I can't find anywhere on the Akka.net web site, except for this posting on github, which says 'it'll be done soon' in 2015.
In case anyone ever asks this question again, my solution was to create an Actor that implemented a tcp connection with optional SSL (using SSLStream) that was compatible with the original System.Tcp().
I am trying find if there is any module or way to get metrics from NGINX and especially about SSL connection (Negotiation time etc.)
I ve searched also in access log but with no luck.
I ve also search to do that using somehow tcpdump to packet analysis
Is there anyway to do that from serve side to take those metrics?
Not sure if this will answer your question but I hope that it can help...
Here are two web pages that I found that provide general information on Nginx metrics (including modules for metrics):
How to Monitor Nginx: The Essential Guide.
An In-Depth Guide to Nginx Metrics.
The first of these includes a section on "SSL Certificate expiration". But monitoring for SSL expiration dates and/or alerts for that seems limited in regards to the SSL connection metrics portion of your question.
On my searching for more SSL specific metric information for Nginx, I came across Module ngx_http_status_module. In the "SSL" subsection of the "Data" section of the page, I found mention of the following SSL statistics:
handshakes
The total number of successful SSL handshakes.
handshakes_failed
The total number of failed SSL handshakes.
session_reuses
The total number of session reuses during SSL handshake.
I also found a paper Nginx SSL Performance that looked interesting to me in regards to Nginx SSL metrics albeit more from the perspective of a basis for what kinds of performance one can expect. It does however point out using openssl speed to gather metrics. Of course this presumes that Nginx was built with OpenSSL as the SSL library.
That leads me to the SSL library that your Nginx is built with. Whether it's OpenSSL or something else, it should have support for logging details. Here's a StackOverflow Q & A that's related to logging SSL details: nginx - log SSL handshake failures. While it doesn't sound like logs were the way you primarily wanted to get metrics from, it does seem like another resource even if you have to write some code to analyze them more conveniently.
Along the lines of analysis, I found the web page Debugging SSL Problems. While it's written with Apache's web server in mind, it does look like it would have helpful suggestions for analyzing and debugging Nginx SSL operations too.
As far as ways that perhaps you can get better answer(s), perhaps asking on the Server Fault Q & A site would help. You'll need to figure out how best to do that however as I recall seeing cross-posting being discouraged. Perhaps this Q & A can just be moved over to there since that seems like a more appropriate site for this. I don't know though.
Incidentally, I've written Nginx modules before and this question got more interesting to me as I dug into answering it.
I have an existing client that is written in ActionScript that I want to completely replace.
Python and Twisted appear to be the ideal candidate. No changes to the server are allowed.
1..What are the possible stumbling blocks?
2..Is it probable that Twisted can be used to create a bit perfect network connection that would be the same as the current client?
The connection is authenticated and uses SSL.
This is too hard to answer without knowing everything about your current client. Try something, and if you have a problem, ask a separate question.
Yes. Twisted doesn't have any restrictions on what kind of network traffic it can create.
Twisted does support SSL out of the box.
I need answer to one very basic question.
Is it necessary to have telnet access to hit an API while systems are connected over VPN? For example, if my system exposed an API for other systems to hit and they are connected in VPN using IPsec, does a third party system needs telnet access to my server for using that API? The API uses soap protocol for receiving request and sending response.
(I did not find out the solution using google. The question is so naive that I had to assume everyone must already know the answer and does not bother to discuss it in web. Sorry for bothering with this simple question)
This is very strange. Accessing an http endpoint for anything else than dev using telnet doesn't really make much sense to me. If someone is using telnet to fetch informations from a server in an application. Something is already really wrong. If telnet is timing out while doing http requests. It's not really your fault and you shouldn't have to worry about edge cases like this.
If the dev is using telnet to discover security issues. This is a different issue and you could probably log anything that come from this particular client. If you gave hime some credentials, it should be easy to find who is doing which request. (I believe you might be already doing this).
You should probably ask the dev "why are you using telnet?". If for whatever reason the dev though he could send a plain SOAP request to your server using telnet without sending HTTP headers and so on.... then yes the connection is likely to timeout because the server isn't going to handle the request.
In my twisted mind, I can imagine some kind of legacy application calling scripts that open telnet sessions to parse some data and return the "parsed" data to the patched legacy project that doesn't handle http/tcp. I'd have in mind some sort of old Cobol application. Much more easier to do system call than to rewrite the whole thing to support APIs.
If for whatever reason, the client claims that telnet is needed for whatever reason. You can tell him back that telnet shouldn't be considered secure. Your api can be accessed using https. As far as I remember telnet doesn't encrypt anything unless you send encrypted data. If your client was able to hack a solution using telnet, I'm pretty sure they can hack a different solution wich use an actual http client.