Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I have server and client running OS Window 7 ultimate. I would like to configure so that server and client communicate under TLS.
At server, I go Local Group Policy-> Remote Desktop Host -> Security to enable Secure Layer to TLS1.0.
When I connect the server from client, I did capture the packet using Wireshark, but I never see the TLS setup .
I did google alot regarding how to set up the TLS. It said that the self-signed cert is not trusted from the trusted root CA. Is it because of this so the TLS can't set up?
Wireshark often can't guess the protocol when the protocol changes on the same connection. This is typically the case for most protocols that upgrade to SSL/TLS on the same connection (using STARTTLS-like mechanisms).
If you want to see this, you have to tell Wireshark to decode the packets as SSL/TLS: right-click and choose Decode As -> Transport -> SSL.
This should work even with a self-signed certificate (typically one is generated automatically and configured by default on a Windows 7 Pro machine, for example). In this case, if you want the connection the be secure, you'd need to verify manually that it is the certificate set up on that machine.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 5 years ago.
Improve this question
I have a server at home and another on a VPS hosting. I tried to create L2TP/IPsec tunnel between them. The tunnel works and one server can access HTTP services from the other server (VPS server is client and server at home is VPN server to which I am connecting and runs HTTP and HTTPS services that I am trying to access from VPS server). But when I try to connect via HTTPS, the connection does not work.
This is what happens when I run this command from the remote server connected to the other one via L2TP/IPsec: openssl s_client -connect SERVER:443:
CONNECTED(00000003)
And if I try wget --verbose https://SERVER/:
Resolving SERVER (SERVER)... SERVERIP
Connecting to SERVER (SERVER)|SERVERIP|:443... connected.
So the connection is started, but no data is exchanged. I have tested with nmap and the port is detected as open.
I tried to connect to this VPN via my laptop and from there, I can access both HTTP and HTTPS services, but from this server, I can only use HTTP. I have tried turning off all firewalls that are on the path of the packets but the problem persists.
I know this is a very specific case so if there is no actual answer to what the problem might be, I am at least looking for guidelines to how to debug this as wget, curl and openssl s_clinent don't provide me any details as they stay on the connection established state.
UPDATE: I have opened 443 port on NAT on the home server and tried to connect to HTTPS service directly from VPS server without VPN and it worked. So only when I access HTTPS via VPN, the connection does not work.
The problem was the MTU setting of the L2TP connection. I had to lower the MTU to 1300 as HTTPS + IPSec add so much overhead that the packet was over 1500, which is the upper limit of the Ethernet and SSL packages set DF (Do not fragment) flag on Layer 3 which disables package fragmentation.
Normally, the server would send special ICMP message to notify the VPN server about this problem but I had ICMP blocked by the firewall so there was no error, just connection was not able to establish as packages had too big size and were just dropped.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 6 years ago.
Improve this question
I have hosted a website using VPS and pointed to it using DNS services of CloudFlare, The site is working properly. Now I am trying to install ssl provided by Lets Encrypt, I am able to complete the steps successfully but the site doesn't appear to be ssl enabled. Also when I completed the steps succesfully the process didn't generate any cert file.I have used the https://www.digitalocean.com/community/tutorials/how-to-secure-apache-with-let-s-encrypt-on-ubuntu-14-04 could anybody tell me were I might be going wrong.
CloudFlare supports using Let's Encrypt between CloudFlare and your origin; however you must use the --webroot argument when you run the Let's Encrypt binary.
By using the webroot authentication method, a temporary file is placed to validate your domain for the certificate. There is a guide on how to do this on the CloudFlare help centre: How to Validate a Let’s Encrypt Certificate on a Site Already Active on CloudFlare
By using this method, you are able to ensure the connection between CloudFlare and your origin web server is fully encrypted using Strict SSL.
Now you have https on your server.
So the communication vpc-cloudfare can use https.
Now you have to configure cloudfare to use https betwenn cloudfare and the browsers.
See https://www.cloudflare.com/ssl/
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I am having a server which supports RC4 SSL Cipher suites. I just want to know whether it is easy for a attacker to determine the contents and IP of the users who are connecting to my server?
Concerning the IP, that is out of scope for SSL. SSL works on top of TCP and thus doesn't even know about IPs. Hiding IPs is hard, since they're required to deliver data to the correct recipient. You can use proxies like TOR to hide your IP.
SSL keeps the content transferred over the encrypted connection secret. RC4 isn't the greatest encryption since it produces a biased bitstream. That allows an attacker to learn your secret data if it's transferred several billion times at a known position close the the beginning of the stream.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
According to http://en.wikipedia.org/wiki/Secure_Shell#Key_management, ssh is vulnerable to "man-in-the-middle" attack when establishing the first connection with server.
SSH also supports password-based authentication that is encrypted by automatically generated keys. In this case the attacker could imitate the legitimate side, ask for the password and obtain it (man-in-the-middle attack). However this is only possible if the two sides have never authenticated before, as SSH remembers the key that the remote side once used.
Does VPN suffer from the same "weakness"?
If VPN server is authenticated using the key which is known to the client, then there's no problem - the key is already known (and supposedly trusted) and the client can be sure that it has connected to the legitimate server.
The same applies to SSH. Wording in wikipedia is not exactly correct - for the first connection to be reliable the client should know the valid server key. It's not important if "they have authenticated before". It's important that the client trusts the key.
How can the key be trusted on the client? When X.509 certificate is used in SSL/TLS, it's validated according to sophisticated rules and the certificate chain is built up to the trusted root certificate. If the chain can't be built, then the end-entity certificate is not trusted. In SSH there are no certificate chains and the only way the client can trust the server is when the client has server's key transferred using some other mechanism (voice call or paper or USB stick or separate SSL/TLS connection, whatever).
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
Mailclients offer both settings, the STARTTLS and SSL/TLS. What is the difference between STARTTLS and SSL/TLS?
The clearest explanation that I've read is from FastMail:
SSL and TLS both provide a way to encrypt a communication channel
between two computers (e.g. your computer and our server). TLS is the
successor to SSL and the terms SSL and TLS are used interchangeably
unless you're referring to a specific version of the protocol.
STARTTLS is a way to take an existing insecure connection, and upgrade
it to a secure connection using SSL/TLS. Note that despite having TLS
in the name, STARTTLS doesn't mean you have to use TLS, you can use
SSL.
Read the rest of the info they have, including a discussion of port numbers and POP/IMAP vs SMTP, here: https://www.fastmail.fm/help/technology_ssl_vs_tls_starttls.html
The question is quite vague, but I guess I understand it. STARTTLS means "explicit TLS" where the connection is established on regular port and then STARTTLS command is sent to initiate SSL handshake and switch to protection mode. Another option probably defines implicit SSL/TLS on a dedicated port. In implicit mode first the handshake takes place and then the application-level protocol runs over the established secure channel.
If you select "TLS if available" Thunderbird will make a TCP/IP connection to the mail server and send a command to ask what capabilities the mail server has. If it says it supports STARTTLS Thunderbird will change the connection to a TLS connection. However, if the mail server doesn't support STARTTLS the connection doesn't fail. Thunderbird continues to use a normal connection. This is a security risk since Thunderbird doesn't display some icon to indicate whether the connection is secure like a browser does, and you're vulnerable to man in the middle attacks (MITM).
Source:
http://kb.mozillazine.org/Secure_connections_-_Thunderbird