I've 2 windows server 2012 R2 with all updates.
this server are behind a firewall with IPSEC connection. So we need to connect to a remote API service and we have some strange situation.
1st server connection ok.
via command line with curl command I star connection and with shark I can see the Hello message with protocol TLSv1.2 and connection works fine.
2nd server connection ko.
via command line with curl command I star connection and with shark I can see the Hello message with protocol SSL.
I try to use .net app and the situation still be the same, 1st ok, 2nd KO. if I try to connect to paypal in TLSv1.2 it work fine. I try with other Win Server 2012/2016 but not works.
Related
I'm using Wireshark to analyse network traffic for a TLS request. I can filter the request based on the website IP address and I can see things like TCP session setup (3-way handshake), client hello, server hello, etc. Based on my understanding I should be receiving a "certificate" packet from the server after the 'Server Hello' where I can see the website certificate as well as any intermediate certificates... but unfortunately I'm not receiving a "certificate" packet...
I've tried this on Windows (Wireshark version Version 3.6.6) and Ubuntu 20.04 (Wireshark version 3.2.3) and it's the same for both.
Should I be receiving a certificate packet? If so, any clues as to why I'm not seeing it?
For the Apache MINA FTP Server SSL FILTER configuration : I tried everything and I read more than 50 posts on stackoverflow to find the error. But still no solution.
Problem Is that,
When the SSL Filter Enabled for the Apache MINA FTP, it is working on server side and at the Server Locally FileZilla Client Can Access to server over implicitSSL it works without problem.
I allowed the 21 port and passive ports over firewall for all ips.
But when the remote client wants to access to the server, SERVER getting request but session.write not works then MINA can not switch to USER exec, SO REMOTE client can not connect FTP server.
But when I disable implicitSSL mode on SERVER side, CLIENT can connect . SO, without SSL, Client Connect Remote SERVER. It is tricky But WHY, what is the problem.
If the problem is firewall , why the client connects when I disable implicitSSL.
If the CODE is or configuration is the problem, WHEN I enable implicitSSL =true, WHY local SERVER filezilla application can connect to server over implicitSSL.
**
Please help.
**
I am trying to setup the basic hello world example.
I am using a t2.micro instance with Ubuntu 14.04 LTS and I have the github code for the example on my local machine.
The url I am using is:
https://localhost:8443/index.html?ws_uri=wss://ec2INSTANCE:8888&ice_servers=[{"urls":"stun:stun.l.google.com"}]#
I do not have the stun or turn configured on the server, but it should be ok since I am passing the stun server to use in the url.
Any advice on this?
I just checked my console and I see this, even though port 8888 is open in AWS Security group that this instance is in
VM8812:35 WebSocket connection to 'wss://ec2Instance:8888/' failed: Error in connection establishment: net::ERR_CONNECTION_CLOSED
I was able to get past the issues that I was seeing
Follow basic instructions on a fresh EC2 (Ubuntu 14.04 LTS), using http://doc-kurento.readthedocs.io/en/stable/installation_guide.html
Add a STUN server in conf
Using stun:173.194.66.127:19302
Tested with http://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/
Secure WS to use WSS, which is required due to HTTPS requirement since Chrome 47, using http://doc-kurento.readthedocs.io/en/stable/mastering/securing-kurento-applications.html#configure-javascript-applications-to-use-https
Uncomment secure section of /etc/kurento/kurento.conf.js
Create the self signed certificate, and placed in /etc/kurento
Go to https://ec2InstanceUrl:8433/kurento and accept insecure connection
Go to example https://ec2InstanceUrl:8443
You must verify that your STUN server is working by seeing something similar to the below image, with the srflx under Component Type.
It seems that on june 11th, something changed on the Nest servers that prevent my software to run properly on windows XP / windows server 2003.
I don't know what changed exactly but now none of the TLS ciphers supported on win XP are accepted by the Nest servers
I tested all of them using curl:
curl -v --tlsv1 --ciphers EXP-RC4-MD5 https://firebase-apiserver05-tah01-iad01.dapi.production.nest.com:9553/devices.json?auth=<my_token>
* About to connect() to firebase-apiserver05-tah01-iad01.dapi.production.nest.com port 9553 (#0)
* Trying 54.196.73.38... connected
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* Unknown SSL protocol error in connection to firebase-apiserver05-tah01-iad01.dapi.production.nest.com:9553
* Closing connection #0
curl: (35) Unknown SSL protocol error in connection to firebase-apiserver05-tah01-iad01.dapi.production.nest.com:9553
If someone from Nest is reading this, would it be possible to enable at least one of the cipher supported by win XP?
alternatively is there a way to have more ciphers supported by SChannel in win XP? For example AES128-SHA works with the Nest servers using curl
Windows XP support ended in April last year (2014) and Windows Server 2003 support ends in a few days (14 July 2015). As a result they are limited to support older, and less secure protocols/ciphers.
I think you are out of luck with this one. If you had to I guess you could proxy the requests from legacy clients via another API that does support the less secure combinations of protocols/ciphers and then forward those requests to Nest. I wouldn't recommend it however.
Just make sure you consider any possible security ramifications.
If you're using a specific .net library for fire base I know one of other person to run into issues. So maybe check your fire base library or try a new one.
I've built a self hosted wcf server, using wsHttpBinding. I'm running Win 2003 server R2 SP2.
If I configure it to listen on http://localhost:443/MyService, everything works fine. I can connect to http://localhost:443/MyService with Internet Explorer, and I get the standard "Bad Request" message
Now, if I try to switch to HTTPS, I'm witnessing a strange phenomenon.
Here's what I've done :
I've changed my wcf config file from http://localhost to https://localhost and from Security=None to Security=Transport (as explained in numerous wcf tutorials)
I've registered my HTTP port like this :
httpcfg delete ssl -i 0.0.0.0:443
httpcfg set ssl -i 0.0.0.0:443 -h ea2e450ef9d4...
Note that the certificate I've used is a "real certificate" (i.e. issued by a trusted CA, namely Comodo). The server responds to ping on the NS mentioned in the certificate.
Now, the following will timeout :
Microsoft Telnet> open localhost 443
Here's the output from netstat (The Pid '4' is the 'System' process):
netstat -nao
Proto Local Adress Remote Adress State Pid
TCP 0.0.0.0:443 0.0.0.0:0 Listening 4
And here's a screenshot from TCPView captured when I issued the open command in telnet :
alt text http://img26.imageshack.us/img26/3376/tcpview2si6.jpg
I'm a bit puzzled. To me, if netstat says the server is listening on 443, the telnet connection to 443 shouldn't timeout, and I should have at least a blank prompt, expecting me to type some encrypted stuff :)
So far I've tried to :
Redo all the steps from scratch following exactly the MSDN tutorial
Used port 10443 instead of 443
Disable the firewall
Use a self signed certificate
I don't know what to try next .. any ideas?
The telnet client is not going to know to send a properly constructed request to initiate an https handshake, so I imagine the ssl secured server is just waiting for more data.
The telnet client is certainly not going to know what to do with the response from a ssl secured server (it's certainly not going to prompt you for data to send along). Communication can only happen once the https handshake has completed.
You need to use a client that knows how to do a handshake. The openssl binary can do this out of the box.
Telnet cannot be used to comunicate with encrited webs.
Checkout this microsfot note. It says "NOTE: This example assumes that the Web server is configured to use the default HTTP port (TCP 80). If the Web server is listening on a different port, substitute that port number in the first line of the example. Also, this example does not work properly over an HTTPS/SSL connection (TCP 443, by default), because the telnet client cannot negotiate the necessary encryption commands to establish the SSL session. Although an initial connection is possible over the HTTPS/SSL port, no data is returned when you issue a GET request."
Update: Checkout this other note HOW TO: Determine If SSL Connectivity Is Not Working on the Web Server or on an Intermediate Device
As FerrariB said, telnet does not perform the negotiations necessary to open an SSL connection. Telnet knows nothing about certificates, nor encryption. Thus, you are guaranteed to not be able to communicate with HTTPS port 443 via telnet. You will have to find another way to do whatever you are trying to do.
Check out the Wikipedia page on TLS for example, where it says directly:
If any one of the above steps fails, the TLS handshake
fails, and the connection is not created.
This is precisely what you are seeing by trying to use telnet to communicate with an SSL endpoint.
in command prompt: netstat -nao |find "443"
the last columns show a number:
pic no.1
Now open task manager.find result number in 1st section in pid column (if pid wasn't enabled, choose it from view tab) program name show the program which uses the port.
disable the program that uses the port /in my case I stopped it from services