I am using WebClient to implement a secure account check before a customer can use my application. but what I am worrying about is "does connecting to a website that uses SSL Certificate using HTTPS protocol prevent MATM attack and makes the whole communication encrypted ?".
In another words: will some programs like Wireshark be able to get the requests and responses in plain text as with using normal HTTP requests ? and is there an ability to alter the sent and received packets ? in order to change my application behavior or something.
[NOTE] I am not talking about getting my application pirated as I know that there is no way to get away from that fate.
HTTPS does prevent Man in the middle attack, as long as both sides are implementing the protocol properly and I assume that WebClient is implemented properly.
That means that even wireshark that is installed on your local box won't be able to decrypt the traffic
If someone in the middle would alter packets on their way, the other side won't be able to read them and the communication would break.
Some clarification given our discussion in your comments:
The above holds if your client is not compromised (HTTPS does work), since you are assuming that your clients will compromise themselves and use tools that will cheat your application by adding fake trusted certificates (which requires admin rights), I can suggest you to use two way ssl.
The tools that I know like Fiddler won't be able to decrypt this just by adding their trusted certificates, thus making it more difficult for your clients to attack your application this way, and bring them to use a debugger or patch it, because it is easier than implementing a two way ssl proxy.
You can also do what's described in this post to override the framework's certificate verification with code that expects one specific certificate and ignores the system's trusted certificates, which is compromised by tools like Fiddler (this implements What Mark suggested).
HTTPS encrypts the transmitted data and prevents man in the middle attacks by authenticating the HOST you are connecting to. However, in regards to a desktop application and also a web application, the user can use wireshark or an http proxy to view the contents of the https transmissions on the local host.
A way to mitigate this problem is to hard code the thumb print of your server cert so that you r application can encure that the server it's connecting to is presenting a specific certificate.
An example, would be if you were to install Fiddler on your local box and install the fiddler root certificate. Your application would think it's securely connecting to the server, but fiddler would be in the middle decrypting traffic. If your application code looks for a specific certificate thumbprint, you can throw an exception when a certificate other than the certificate you expect is used to connect, thus preventing the transmission of any data when a local proxy is in use.
Wireshark will always be able to see the packets being transmitted over the network but you won't necessarily be able to see the contents of the transmission unencrypted. However I'm not an expert in using Wireshark, so maybe someone else here can expound on that.
UPDATE
Ok to clarify more.... this question is discussing the encryption of contents being sent from a desktop application to a server.
Let's layout some assumptions:
The user of the desktop application, controls their desktop.
The application installed on the desktop is using a public key to encrypt.
Anyone with the corresponding private key can decrypt.
Since the user controls their desktop they can also run an http proxy on their desktop.
Now the way SSL(HTTPS) works is that your browser starts a secure handshake, at which point the server will return the public certificate, and your browser will attempt to authenticate that certificate with the authority you puchased the certificate from like (godaddy, geotrust, or versign, etc)
Assuming the user installed fiddler and it's root certificate, your desktop application would connect to fiddler, and be served fiddlers public root certificate, which it would validate against the locally certificate store and deem it trusted. Fiddler would then contact the server, which would send it the real public certificate.
Subsequently your http request from the browser is encrypted by the browser using the fiddler root public key, fiddler then decrypts the contents, and then reencrypts it using the public key from your server (mydomain.com) and forwards the request to the server, which then decrypts it and processes it.
Here is more information: http://en.wikipedia.org/wiki/HTTP_Secure
SSL offloading(https://f5.com/glossary/ssl-offloading) is also a feature used in network infrastructure for offloading the SSL load on other devices than web services. This is a form of man in the middle decryption of content. Also, Instrustion Detection systems in enterprise networks can have SSL certificates installed in them allowing these devices to decrypt the contents of requests and inspect them for behaviors indicative of network attacks.
Related
I'm writing a VB6 application which connects with SQL Server. To secure the connection with the database I'm using MSOLEDBSQL as provider which supports TLS 1.2. I also enabled TLS 1.2 in my machine. I verified the connection status using sys. dm_exec_connections and SQL server displays all the connections are encrypted. To double confirm I tried to use the echomirage to check the traffic and the results are surprising. The data is not encrypted and I can read all the data flow as shown in the below image. My question is
This communication is really encrypted. If not why I'm seeing different status in SQL server
I read somewhere that TCP is binary protocol. If so, why I'm seeing plain text even if this communication is not encrypted?
This isn't a TDS issue (the protocol used by SQL Server). The same thing happens with your browser when you use a debugging proxy like Fiddler and trust the proxy's certificate, or configure it to use a trusted certificate. Most likely, you trusted EchoMirage's certificate during setup or through its Settings and forgot about it.
SSL/TLS protect agains Man-In-The-Middle attacks by verifying the other party through certificates. Encryption isn't enough. Without verification a proxy between client and server could pose as the other party, set up encrypted communications with each side, decrypt the packets it receives, inspect them and then encrypt them again using the other side's keys and send them along. Without verification neither client nor server would know someone intercepted the connections.
With SSL/TLS, a connection is established only if both parties trust each other's certificates. Both sides verify the certificates by checking either whether the certificate is explicitly trusted, or if it was issued by a Certificate Authority trusted by the application. If validation fails, the connection fails as well.
Fiddler, WireShark and other similar tools decrypt traffic by acting like a proxy and establishing communications on either side using their certificate. With certificate validation enabled though, the browser (or the SQL Server client) would reject the connection. If you try to connect to a web site through HTTPS while Fiddler is in use you'd get a red warning page saying that the connection isn't safe.
To allow such connections someone would have to go and explicitly trust the tool's certificate. All tools can do this through their settings, but all OSs require privilege elevation and user confirmation before they add the certificate to their trusted list.
By default, drivers and network libraries perform validation. To allow WireShark to intercept the SQL Server connection you'd have to either explicitly disable validation with TrustServerCertificate=true;, or trust the tool's certificate, which is probably something you already did and forgotten about it.
The page Using Encryption Without Validation in SQL Server Native Client in the docs explains what happens when you don't use validation, and warns against it.
If you use Encrypt=true and leave TrustServerCertificate to its default, false, WireShark or EchoMirage won't be able to intercept, much less decrypt the traffic. In this case :
Encryption occurs only if there is a verifiable server certificate, otherwise the connection attempt fails.
This is a TDS issue (the protocol used by SQL Server), and is not caused by WireShark in any way.
TLS encryption is only used during the login process to ensure that the credentials are not passed unencrypted over the network.
After that, the remaining bulk-transfer of queries and result sets are not encrypted on the wire.
In order to enable encryption for data (and not just for the login process), you need to use the Use Encryption for Data connection string keyword in your connection string:
Use Encryption for Data=true
Use Encryption for Data
SSPROP_INIT_ENCRYPT
"Specifies whether data should be encrypted before sending it over the network. Possible values are "true" and "false". The default value is "false"."
Be aware: If you enable encryption for data, and the server doesn't have a valid certificate (i.e. the default), then you will get an error when connecting. The client will detect the server presented an invalid certificate, and stop the connection. In order to make your system reliable, you need to include Trust Server Certificate=true in your connection string:
Use Encryption for Data=true;Trust Server Certificate=true
A better alternative is to turn on the option on the server that forces encryption for data, and do not specify Use Encryption for Data or Trust Server Certificate in your connection string.
When it is the server that requires the encryption, the client will not care about the certificate presented by the server (excluding MSOLEDBSQL19, which is broken by default, and you will need to specify Trust Server Certificate=true even when it was the server who wanted the encryption in the first place.
I have a server application that uses TLS1.1 for authentication. Encryption is done with RSA-1.
The communication between this server and a windows client application works ok, but in the real world, the server application communicates with a small device that has limited memory.
It turns out that the initial handshake produces data packets that are too big for the device to handle (increasing the buffer size is not within my control), so my question is:
is it possible in .net to configure the ssl handshake process in more detail and if so, how?
I am thinking of minimizing the list of distinguished names that the server sends to the client (during certificate request), which it uses to build the 'acceptableIssuers' list (without actually removing all the trusted CA certificates) or any other way to pinch a few bytes of the handshake process?
Thank you.
The largest part are the certificates send by the server. To reduce this size:
Send only the necessary certificates. Of course you need the leaf certificate (from the server).
If you have any intermediate certificates try to install them as trusted at the client, so that you don't need to send them.
And of course don't send the certificate of the root-CA, this should be at the client anyway.
If this is not enough you might need to get another certificate with a smaller key size, i.e. use 1024 bit but not 2048. 512 bit is too small for today and even with 1024 bit you might be in trouble in a few years.
As suggested in the first comment on the first post, change the registry setting to remove the list of distinguished names from the handshake:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL
Method 3: Configure Schannel to no longer send the list of trusted root certificate authorities during the TLS/SSL handshake process
I have succeeded in publishing a website in HTTPS through IIS using this tutorial:
http://www.iis.net/learn/manage/configuring-security/how-to-set-up-ssl-on-iis
Now, even though the digital certificate is not valid since it was issued by my computer, the website supposedly uses HTTPS. However, after I log-into an account, I am still able to see the form data entered using Google Chrome developer tools.
Why is this happening? Isn't HTTPS supposed to encrypt network traffic? How can I solve this problem please?
The browser is likely doing some work for you in decrypting it. Try using a tool like Fiddler (http://www.fiddler2.com/fiddler2/) to grab network traffic outside the browser environment. Fiddler also allows you to decrypt HTTPS traffic, but it's not enabled by default.
It gets encrypted by the secure sockets layer (SSL) before it enters the transport layer. What you see in f12 tool in a browser is what gets sent to the SSL layer. The traffic that gets sent over the wire is captured by tools like fiddler and wireshark.
I wanted to know what is the best way to write an agent on Win platform that will be able to monitor browser's communication.
scenario: monitor the user access to predefined url on Chrome, FireFox and IE. On each hit I send the stats to a server with some data (page title).
The ways I found so far are proxy and browser addons. Each has it's own advantages and disadvantages. The main disadvantage of the proxy way is handling of HTTPS communication. The addon disadvantage is the installation (need to install on every browser) and cross-browser support.
Is there another way? some service I can write with .net that will automatically hook on a browser when it is started?
Thanks you.
You do have only two choices - an http proxy, or to write a plugin for every browser. That plugin could just forward data via network to a central service, leaving you with the challenge of coming up with a common set of data that all browsers can provide, plus learning all the plugin models.
In my opinion, though, the only real option is an HTTP(s) proxy because otherwise you have to keep updating your plugins every time browsers change, or deal with the fact that new browsers can come along and be used.
Certainly you won't find a 'user is browsing a url in some browser' event in the OS - all it knows is that a socket connection has been opened on some local port to a remote server's port 80/443 (or whatever).
So I strongly suggest building on top of the excellent work that's behind Fiddler and use the Fiddler Core.
http://www.telerik.com/fiddler/fiddlercore
For https you have to decrypt and re-encrypt with a different certificate. The information that you need is just not available without actually unpacking the request. Fiddler achieves this by opening it's own SSL tunnel to the target server on the client's behalf, whilst acting as an SSL server to the client under a different certificate. So long as the certificate that it uses is fully trusted by the client, no problems occur.
That said, it means that the user cannot personally verify the identify of the target site - therefore your system would have to assume worst case scenario for any invalid SSL certificates and block the connection.
I am trying to send information (in the form of an mime file) to a third party host server that uses two way authentication. After much coaxing I got enough information from their non technical help desk staff to figure out that it is most likely a type of TLS/SSL communication. They use client and server handshakes. I found the following example:
sslstream example. But am having problems using it (TcpClient refuses to see the host adddress).
Before I get too far I was hoping some one could point me in the direction of some good examples or more information on this process. I'm feeling pretty lost.
By two way authentication, probably they mean that they require a client certificate. This means that during the handshake, the client side has to present a certificate to the server as well. The most common SSL behavior is that only the server part presents a certificate, such as when you go to a normal site that is using HTTPS.
As for SslStream, it is quite straightforward to use. To be able to present a client certificate, you need to have a certificate in the certificate store or a pfx file that you can load into memory during runtime.
I found this sample which seems good enough. Here is another one. The second one doesn't use client certs, but you can add them as a parameter to the the AuthenticateAsClient call.
If the TcpClient is refusing to see the host address, then this is most likely some kind of connectivity issue and not related to the actual SSL implementation.