I have a very specific question about the transport encryption used at Windows Communication Foundation. I wrote a client and a service application.The service is hosted as Windows Service and started with a special user, let us say Jeremy.
My client is on a seperate computer but in the same domain. Communication happens over a net.tcp binding with a transport encryption.
Problem 1: if i sniff with wireshark, the first packages are in clear text
Problem 2: in the App.config of the client is a auto-generated identity-tag in the form of "jeremy#mycompany.com". If i set it blank everything is send in clear text. If i delete it, the program won't work.
Is anybody able to describe what exactly happens during the handshake? I thought Kerberos is fetching a ticket at the service to authenticate the client. But why is it in clear text then?
I hope somebody is able to help.
Edit: The clientCredentialType is of course Windows with protectionLevel: encryptAndSign
Ok after a lot of research I found out that this happend due to a discrepancy of Kerberos an NTLM.
The cleartext I mentioned is the handshake between server and client. So if I use Kerberos the clear text are only some chars which calls the service. If Kerberos is then not available or if you change the identity tag Kerberos falls back to NTLM which is responsible vor a much longer handshake and so on a few more clear text passages. I now forced the client to use Kerberos with following line:
<endpointBehaviors>
<behavior>
<clientCredentials>
<windows allowNtlm="false"/>
</clientCredentials>
</behavior>
</endpointBehaviors>
At the windows security logs you can now see that authentication happens via Kerberos.
Here the links that helped me most to understand Kerberos and solve the problem:
https://blogs.msdn.microsoft.com/asiatech/2009/08/27/how-to-impersonate-or-delegate-a-client-in-wcf/
https://www.tecchannel.de/a/die-funktionsweise-von-kerberos,461645
https://msdn.microsoft.com/en-us/library/59hafwyt(v=vs.100).aspx
Related
I'm able to get an unsecured FTP Client/Server system going, but when I try throwing in the SSL io handlers, setting up both apps to use sslvTLSv1, it shows Connected for the Client status then eventually times out (the only Server message I get is Socket Error # 10060).
After many trials and tribulations trying to resolve this issue, I've determined that there are serious problems with enabling a certificate-less security system; meaning that, if you want it secured (with the current Indy code), you need to use certificates. Perhaps there are some settings in the SSL component that need to be made, but there just isn't specific enough info (working examples of certificate-less SSL) to make this work. Hopefully this deadlock will be resolved in a future release of Indy ;)
I feel lost trying to figure out what my options are. Apache's programmers guide and administrators guide do not detail anything substantial. My O'Reilly Zookeeper book barely talks about security... did I miss something? I was hoping to find tutorials through google about authenticating client connections, authorizing actions, and encrypting messages sent between zookeepers and client.
I had a lot of trouble but I figured it out and the links at the bottom where a huge help to me.
This code (using Curator) was something hard to figure out:
List<ACL> myAclList = new ArrayList<ACL>();
aclList.add(new ACL(ZooDefs.Perms.ALL, ZooDefs.Ids.AUTH_IDS));
client.create(withACL(myAclList)).forPath(myPath);
If I setup the zookeeper configuration correctly, then it will enforce that only the AUTH_IDS will be allowed to access my ZNode.
Ofiicial documentation, My mailing list Q1, My mailing list Q2, JIRA that I found useful, but some items are out of date
Since zookeeper version 3.5.4-beta, you are able to enable using client certificates to secure communication to a remote zookeeper server:
Client
ZooKeeper client can use Netty by setting Java system property:
zookeeper.clientCnxnSocket="org.apache.zookeeper.ClientCnxnSocketNetty"
In order to do secure communication on client, set this Java system property:
zookeeper.client.secure=true
Note that with "secure" property set the client could and should only connect to server’s “secureClientPort” which will be described shortly.
Then set up keystore and truststore environment by setting the following Java system properties:
zookeeper.ssl.keyStore.location="/path/to/your/keystore"
zookeeper.ssl.keyStore.password="keystore_password"
zookeeper.ssl.trustStore.location="/path/to/your/truststore"
zookeeper.ssl.trustStore.password="truststore_password"
Server
ZooKeeper server can use Netty by setting this Java system property:
zookeeper.serverCnxnFactory="org.apache.zookeeper.server.NettyServerCnxnFactory"
ZooKeeper server also needs to provide a listening port to accept secure client connections. This port is different from and running in parallel with the known “clientPort”. It should be added in “zoo.cfg”:
secureClientPort=2281
All secure clients (mentioned above) should connect to this port.
Then set up keystore and truststore environment like what client does.
More info here:
https://cwiki.apache.org/confluence/display/ZOOKEEPER/ZooKeeper+SSL+User+Guide
I need to secure my .NET Remoting by SSL.
I'm using TCPChannel and I can't switch to HTTPChannel and use IIS to add the SSL.
Thus, what I figured out, I need to create my own Sink that will encrypt the streams going to/from Client/Server. For that, I found good article at MSDN: http://msdn.microsoft.com/en-us/magazine/cc300447.aspx. However, that article is developing the crypt, handshake, etc.
I do not want to "reinvent the wheel". I'm afraid of making mistakes when developing this logic on my own. I would rather like to use some SSL implementation (e.g. SslStream or OpenSSL) that will do that stuff for me.
Can I use SslStream or OpenSSL in .NET Remoting with the TCPChannel?
Would you suggest a simple usage?
Thank you for your help.
Consider switching over to WCF.
Alternatively, Remoting should be able to do the equivalent of using WCF with ClientCredentialType set to Windows, if you specify secure='true' in your remoting configuration on both client and server side. TcpChannel will start using SSL under the hood to encrypt the communication, using user credentials for key material. On client side, this also has the implied effect of setting tokenImpersonationLevel='identify' which means that the server will not impersonate the user account under which the client is executing, but it will know who connected to it (assuming the client and the server run in the same AD domain). For performance reasons, set useAuthenticatedConnectionSharing to true on the client side.
I have a classic ASP website running on a Windows Server 2012 box. One page makes a HTTP request to another application over https using code like this:
Sub ShopXML4http(url, inStr, outStr, method, xmlerror)
Dim objhttp
Set objhttp = Server.CreateObject ("MSXML2.ServerXMLHTTP.6.0")
objHttp.open method, url, false
If Method="POST" Then
objHttp.Send instr
Else
objHttp.Send
End if
outstr=objHttp.responseText
Set objhttp=nothing
End Sub
This code works fine almost all of the time (thousands of requests per day), but sporadically it will fail with a message like this:
Number: -2147012739
Description: An error occurred in the secure channel support
Source: msxml6.dll
The application was recently moved from an old Windows 2003 Server to the 2012 Server, and this issue never seemed to be a problem on the old server. In addition, while this error is happening on the website, I could run the exact same code in a VBScript and it works fine. Resetting the application pool seems to cause the site to be able to do the secure HTTP requests again (although it often fixes itself before I can get to the server).
I have had the exact same problem after migrating from 2003 to 2008 R2 and found the solution. Change:
Set objhttp = Server.CreateObject ("MSXML2.ServerXMLHTTP.6.0")
to:
Set objhttp = Server.CreateObject ("MSXML2.XMLHTTP.6.0")
and your problem will go away.
I tried to find the pros and cons about both objects, but haven't yet found a reason to not use XMLHTTP.
I've had the same issue and tried lots of solutions offered under a variety of posts but ultimately had no success, until now. I'll detail the solution that worked for me with reference to the problem as in my case it was PayPal. I've not opened a new post as this might not be just a paypal issue in future.
The solution is a combination of a number of stackoverflow posted solutions to similar problems but this seemed the best one to add to.
The problem
Trying to test PayPal IPN on Windows Server 2008 using classic ASP using the PayPal Sandbox returns the error "An error occurred in the secure channel support".
Why it is a problem
PayPal is requiring all communications with their systems to be as secure as possible. You will need a connection that is TLS 1.2. Windows Server 2008 is not TLS 1.2 by default.
PayPal threw some confusion into the mix by saying you need a Verisign G5 certificate, which you do for the server root but not the domain you are running your code on. I also didn't install any PayPal certificates as I don't use the API. I don't believe you need your comms from an HTTPS site either - although my domain is secured using a standard GoDaddy EV cert although I did a test on a non HTTPS site after and that worked too.
My solution
First check which kind of security your server is using via SSL Labs.
It should be TLS1.2 or higher and no other TLS's or SSL's. It must also have a SHA256 encryption.
You may need to patch the server: https://support.microsoft.com/en-us/kb/3106991.
Use IISCrypto to set the correct TLS and ciphers. I used the registry changes offered up elsewhere on stackoverflow but this did not work and actually totally screwed up my server for everything using HTTPS posts, not just my development site! IISCrypto also handles the ciphers.
Make sure your application pool is v4.5, which in itself is unclear because IIS might only offer v4.0 as an option. However this is probably actually v4.5. You can verify this via https://msdn.microsoft.com/en-us/library/hh925568(v=vs.110).aspx.
Within your code you need to use Server.CreateObject ("MSXML2.XMLHTTP.6.0"), not Server.CreateObject ("MSXML2.ServerXMLHTTP.6.0") as mentioned above.
Now I've no idea why the non-server XMLHTTP works as that seems contrary to the documentation behind it. Right now, after 10 days of stress, panic and frustration I don't care! I hope this is useful for others.
Finding the solution was a nightmare so I'll add some phrases below to help others if searching:
PayPal IPN failing with server error
PayPal SSL Windows 2008 errors
An error occurred in the secure channel support
classic ASP PayPal Sandbox SSL errors
I'd like to publicly thank Rackspace and GoDaddy for their help with this. I'd like to publicly state that I found paypal have the worst technical support ever and just do not care, constantly pointing to their own docs, if they ever respond. They say they've been sending emails out about this since September 2014 but I never received one. These new requirements are active on the PayPal Sandbox but go live in September 2016. I only came across it as developing a new solution so needed the sandbox - if you're running live you won't know about the problem until it hits and then you're dead in the water. Test your entire payment system on the PayPal sandbox asap is my advice!!
None of the answers above applies to my situation. Then I hopped on the link here:
https://support.microsoft.com/en-za/help/3140245/update-to-enable-tls-1-1-and-tls-1-2-as-a-default-secure-protocols-in
This update provides support for Transport Layer Security (TLS) 1.1 and TLS 1.2 in Windows Server 2012, Windows 7 Service Pack 1 (SP1), and Windows Server 2008 R2 SP1.
Applications and services that are written by using WinHTTP for Secure Sockets Layer (SSL) connections that use the WINHTTP_OPTION_SECURE_PROTOCOLS flag can't use TLS 1.1 or TLS 1.2 protocols. This is because the definition of this flag doesn't include these applications and services.
This update adds support for DefaultSecureProtocols registry entry that allows the system administrator to specify which SSL protocols should be used when the WINHTTP_OPTION_SECURE_PROTOCOLS flag is used.
This can allow certain applications that were built to use the WinHTTP default flag to be able to leverage the newer TLS 1.2 or TLS 1.1 protocols natively without any need for updates to the application.
This is the case for some Microsoft Office applications when they open documents from a SharePoint library or a Web Folder, IP-HTTPS tunnels for DirectAccess connectivity, and other applications by using technologies such as WebClient by using WebDav, WinRM, and others.
This update will not change the behavior of applications that are manually setting the secure protocols instead of pass the default flag.
Client service on Windows 2008 R2 server outbound to server over TLS reciprocated the error in question. I thought it could be cipher suite compatibility. Wireshark trace indicated version in Client Hello request was TLS 1.0 but server requires TLS 1.2. The cipher suites sent to outbound server from client service were fine. The problem is the client service or application on Windows server default employs the system default, which is not TLS 1.2.
The solution is to add a registry subkey named DefaultSecureProtocols with a value corresponding to which TLS version(s) should be supported. Add said registry subkey, with type DWORD, to the following locations:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp
For Internet Explorer fix, you can add a similar registry subkey titled SecureProtocols, also with type DWORD, to the following locations:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings
Below you can find the table of values for both subkeys:
DefaultSecureProtocols Value Protocol enabled
0x00000008 Enable SSL 2.0 by default
0x00000020 Enable SSL 3.0 by default
0x00000080 Enable TLS 1.0 by default
0x00000200 Enable TLS 1.1 by default
0x00000800 Enable TLS 1.2 by default
For example:
The administrator wants to override the default values for WINHTTP_OPTION_SECURE_PROTOCOLS to specify TLS 1.1 and TLS 1.2.
Take the value for TLS 1.1 (0x00000200) and the value for TLS 1.2 (0x00000800) then add them together in calculator (in programmer mode), the resulting registry value would be 0x00000A00.
I applied 0x00000A00 as the value for both subkeys and it successfully resolved the issue.
There is also an Easy Fix (link is here: https://aka.ms/easyfix51044) available from Microsoft, if you don't wish to manually enter registry subkeys and values.
It's all valid however the 'critical' missing bit for TLS1.2 support on Windows 7 with IIS7.5 and classic asp is setting this in the registry:-
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp]
"DefaultSecureProtocols"=dword:00000800
I hope that saves you a day of faffing, rebooting and head scratching! :)
This code snippet is useful for testing. https://www.howsmyssl.com/
<%
Set winhttp = Server.CreateObject("WinHTTP.WinHTTPRequest.5.1")
winhttp.open "GET", "https://howsmyssl.com/a/check", False
winhttp.Send
Response.Write winhttp.responseText
%>
In a Windows Server 2016 Classic ASP script, fetching an HTTPS URL from Windows Server 2012 R2, I recently had to remove SSL 2.0 from SecureProtocols in order to stop this secure channel error -2147012739.
' Use the latest client
Set httpClient = Server.CreateObject("WinHttp.WinHttpRequest.5.1")
' allow only TLS 1.2 or TLS 1.1
Const WHR_SecureProtocols = 9
httpClient.Option(WHR_SecureProtocols) = &h0800 + &h0200
' Other values: TLS 1.0 &h0080, SSL 3.0 &h0020, SSL 2.0 &h0008
' NB Including SSL 2.0 stops https to Windows Server 2012 R2 working
' Other options you may want to set, from https://learn.microsoft.com/en-us/windows/desktop/winhttp/winhttprequestoption
' Ignore certificate errors
Const WHR_SslErrorIgnoreFlags = 4
httpClient.Option(WHR_SslErrorIgnoreFlags) = &h3300
' Don't bother checking cert, or risking failure if we can't check
Const WHR_EnableCertificateRevocationCheck = 18
httpClient.Option(WHR_EnableCertificateRevocationCheck) = False
Troubleshooting error codes:
-2147012739 is a HRESULT.
In hexadecimal that's 0x80072F7D.
Look at the LOWORD: 0x2F7D.
Convert that back to decimal: 12157.
Lookup 12157 error codes.
Find that it matches: ERROR_WINHTTP_SECURE_CHANNEL_ERROR
A bit of Google-fu finds http://msdn.microsoft.com/en-us/library/windows/desktop/aa383770(v=vs.85).aspx which states:
ERROR_WINHTTP_SECURE_CHANNEL_ERROR
12157
Indicates that an error occurred having to do with a secure channel (equivalent to error codes that begin with "SEC_E_" and "SEC_I_" listed in the "winerror.h" header file).
However, you already discovered this as the message you got was "Description: An error occurred in the secure channel support". So this leads us right back where we started.
The other observation I make is that your code is a non-asynchronous WinHTTP request (I know it has to be to function inside ASP), but, the concern is, due to the high frequency, your machine could be processing more than one WinHTTP request concurrently. I've seen some Windows deliberately throttle the total number of active concurrent WinHTTP request by blocking the late requests. For example, on a Windows 7 machine a process cannot make more than 2 concurrent requests to the same remote server. i.e. The 3rd, 4th... requests will be blocked until the first two complete.
One solution is to load balance incoming request over more than one application pool or over more servers.
We had a variation on this issues and it really cost us some time to figure it out.
Here is the situation: An older Linux server hosting an application written in PHP and provides data through webservice calls. The server is using HTTPS. Calls from various clients are made with code using the winHTTP 5.2 library. (Winhttp.dll)
Symptom: Our clients are now getting sporadic error messages when making repeated winHTTP calls using a ‘POST’ command. The messages are either ‘The buffers supplied to a function was to small.‘ or ‘An error occurred in the secure channel support ‘. After much searching we discovered that the client’s server was logging ‘Schannel Event ID 36887 alert code 20’ in the Event Viewer that corresponded with the visible error message.
Solution: We discovered that our old Linux server could not support TLS 1.2. (CentOS 5.11) We also learned that several of our clients had recently (summer 2016) applied an update to their Microsoft servers. (Server 2008, server 2012) The fix was to force their servers to use TLS 1.1 for the webservice calls. The part that is rather strange to me is that the settings in Internet Explorer for changing the TLS had no effect on the problem. However by changing a setting in Group Policies we were able to solve the problem. Our technical advisor on this matter pointed out that the change is really obscure, but that a third-party vendor has provided a quick solution. That tool is called IIS Crypto from Nartac. https://www.nartac.com/Products/IISCrypto/Download
The tool lets you specifically select Protocols.
We are now getting a new server to host our applications (CentOS 6) and then should be able to use the TLS 1.2 protocol!
I encountered this error a few months ago myself. Most often, this issue is caused by an invalid SSL cert. Considering that at the time of the post you had just migrated to a new server, you probably just need to reinstall the SSL certificate.
I realize this question is old, but hopefully someone else can benefit from my answer.
I have a couple questions about SSL certificates.
I never used them before but my current project requires me to do so.
Question 1.
Where should you use SSL? Like I know places like logging in, resetting passwords are definite places to put it. How about once they are logged in? Should all requests go through SSL even if the data in there account is not considered sensitive data? Would that slow down SSL for the important parts? Or does it make no difference?(sort of well you got SSL might as well make everything go through it no matter what).
Question 2.
I know in smtp you can enable SSL as well. I am guessing this would be pretty good to use if your sending say a rest password to them.
If I enable this setting how can I tell if SSL if it is working? Like how do I know if it really enabled it? What happens if the mail server does not have SSL enabled and your have that boolean value enabled. Will it just send it as non SSL then?
With an SSL connection, one of the most expensive portions (relatively speaking) is the establishment of the connection. Depending on how it is set up, for example, it might create an ephemeral (created on the fly) RSA key for establishing a session key. That can be somewhat expensive if many of them have to be created constantly. If, though, the creation of new connections is less common (and they are used for longer periods of time), then the cost may not be relevant.
Once the connection has been established, the added cost of SSL is not that great although it does depend on the encryption type. For example, using 256-bit AES for encryption will take more time than using 128-bit RC4 for the encryption. I recently did some testing with communications all on the same PC where both client and server were echoing data back and forth. In other words, the communications made up almost the entire cost of the test. Using 128-bit RC4 added about 30% to the cost (measured in time), and using 256-bit AES added nearly 50% to the cost. But remember, this was on one single PC on the loopback adapter. If the data were transmitted across a LAN or WAN, then the relative costs is significantly less. So if you already have an SSL connection established, I would continue to use it.
As far as verifying that SSL is actually being used? There are probably "official" ways of verifying it, using a network sniffer is a poor man's version. I ran Wireshark and sniffed network traffic and compared a non-SSL connection and an SSL connection and looked at the raw data. I could easily see raw text data in the non-SSL version while the SSL "looked" encrypted. That, of course, means absolutely nothing. But it does show that "something" is happening to the data. In other words, if you think you are using SSL but can recognize the raw text in a network sniff, then something is not working as you expected. The converse is not true, though. Just because you can't read it, it does not mean it is encrypted.
Use SSL for any sensitive data, not just passwords, but credit card numbers, financial info, etc. There's no reason to use it for other pages.
Some environments, such as ASP.NET, allow SSL to be used for encryption of cookies. It's good to do this for any authentication or session-ID related cookies, as these can be used to spoof logins or replay sessions. You can turn these on in web.config; they're off by default.
ASP.NET also has an option that will require all authenticated pages to use SSL. Non-SSL requests get tossed. Be careful with this one, as it can cause sessions to appear hung. I'd recommend not turning on options like this, unless you really need them.
Sorry, can't help with the smtp questions.
First off, SSL is used to encrypt communications between client and server. It does this by using a public key that is used for encryption. In my opinion it is a good practice to use it for as anything that has personally identifiable information or sensitive information.
Also, it is worth pointing out that there are two types of SSL authentication:
One Way - in which there is a single, server certificate - this is the most common
Two Way - in which there is a server certificate and a client certificate - the client first verifies the server's identity and then the server ids the client's id - example is DOD CAC
With both, it is important to have up to date, signed, certificates by a reputable CA. This verifies your site's identity.
As for question 2, yes, you should use SSL over SMTP if you can. If your emails are routed through an untrusted router, they can be eavesdropped if sent without encryption. I am not sure about the 'boolean value enabled' question. I don't believe setting up SSL is simply as easy as checking a box though.
A couple people have already answered your Question 1.
For question 2 though, I wouldn't characterize SMTP over SSL as protecting the message. There could be plenty of points at which the message is exposed. If you want to protect the message itself, you need S/MIME, or something similar. I'd say SMTP over SSL is more useful for protecting your SMTP credentials, so that someone cannot grab your password.