We Keep Coding

Error when calling asmx endpoint on server with TLS 1.3 only

I have an application that calls an ASMX web service which is situated on another server.
Recently, this server had been reconfigured to disable all TLS versions except for 1.3. This resulted in my application failing to call the ASMX with the following error:
Could not establish secure channel for SSL/TLS with authority '[website]'.
The application was compiled under .NET 4.5 which doesnt have an option to specify to use TLS 1.3. So i recompiled it under 4.8 with the relevant specification to use TLS1.3:
System.Net.ServicePointManager.SecurityProtocol = System.Net.SecurityProtocolType.Tls13;
var basicHttpBinding = get_binding(); //returns either basicHTTpsBinding or basicHttpBinding
basicHttpBinding.MaxBufferPoolSize = maxBufferPoolSize;
basicHttpBinding.MaxBufferSize = maxBufferSize;
basicHttpBinding.MaxReceivedMessageSize = maxReceivedMessageSize;
String webServicesEndpointAddress = "url"
var endpointAddress = new EndpointAddress(webServicesEndpointAddress);
new ChannelFactory<customType>(basicHttpBinding, endpointAddress).CreateChannel();
var webServices = new webserviceSoapClient(basicHttpBinding, endpointAddress);
...
//code to call one of the web service functions
This however now results in a new error:
"An error occurred while receiving the HTTP response to [url] This could be due to the service endpoint binding not using the HTTP protocol.
This could also be due to an HTTP request context being aborted by the server (possibly due to the service shutting down). See server logs for more details.
enter code here
Any ideas what could be causing the above error? I am running the application locally in visual studio over windows 10

WCF service sometimes rejects client credentials

I have a WCF service that creates its own secondary IP (using netsh) upon startup and listens on that IP. Sometimes it just so happens that the when server starts listening clients from the same machine can't connect (client credentials are rejected). From other machines, however, there are no such connection problems.
When starting service on the original IP, connection problems don't seem to occur, but the non-deterministic behavior of the previous scenario prevents me from making any conclusions.
This is what is used for credentials and protection level:
TcpClientCredentialType clientCredentialType = TcpClientCredentialType.Windows;
ProtectionLevel protectionLevel = ProtectionLevel.EncryptAndSign;
I would like to know what is happening here. Any suggestions/insights are welcome.

WCF with windows auth and SSL

I want to implement an WCF-Service that uses an TCP transport layer secured by TLS/SSL and still use windows authentication(kerberos/NTLM) on the server to identify the calling client.
The part with the windows authentication already works but I'm not sure if the connection is encrypted.
I'm using a NetTcpBinding and create it like this:
var binding = new NetTcpBinding()
{
ReceiveTimeout = TimeSpan.FromMinutes(30),
OpenTimeout = TimeSpan.FromMinutes(1),
CloseTimeout = TimeSpan.FromSeconds(30),
MaxReceivedMessageSize = int.MaxValue,
ReliableSession =
{
Enabled = true,
InactivityTimeout = TimeSpan.FromMinutes(1)
},
Security =
{
Mode = SecurityMode.Transport,
Transport =
{
ClientCredentialType = TcpClientCredentialType.Windows,
ProtectionLevel = ProtectionLevel.EncryptAndSign,
SslProtocols = SslProtocols.Tls12
}
}
};
I already sniffed some packages with wireshark and found the following in one of the first packages: "application/negotiate".
I just want to be 110% sure the connection is encrypted with TLS but I'm not because i don't know how to check for it.
Client certificates are not possible in my environment.
Please dont just paste a link to some microsoft-website on how to set things up.
There is no example that shows how to use both windows auth and TLS.
The application is standalone, so there is no IIS or something!
Any help is appreciated!

This is example for Net.Tcp binding with transport security and standalone hosting: https://learn.microsoft.com/en-us/dotnet/framework/wcf/feature-details/transport-security-with-windows-authentication
It has almost exact configuration as you do. The only exception is that you add reliable sessions (this does not affect security at all) and limit available SSL protocols to Tls12 only (default value is Ssl3 | Tls | Tls11 | Tls12). So, it's still secure.
So, the answer is: yes, it is secured.

Connect to TFS from C# via HTTP proxy

I'm writing a small C# reporting application for TFS 2012.
TFS server is remote and can be accessed only via HTTP proxy server in the network, as firewalls block direct access.
The proxy is configured in Internet Explorer, so I can open TFS URL in IE, and also it's automatically used by Visual Studio when working with TFS.
The problem is that my application ignores IE proxy settings and tries to connect to TFS server directly (I see this in Wireshark), so it fails after a timeout due to firewalls.
Here is the code I use:
Uri TfsCollectionURL = new Uri("...");
NetworkCredential credential = new System.Net.NetworkCredential(Username, Password, Domain);
TfsTeamProjectCollection collection = new TfsTeamProjectCollection(TfsCollectionURL, credential);
collection.EnsureAuthenticated();
ICommonStructureService projectService = collection.GetService<ICommonStructureService>();
foreach (ProjectInfo project in projectService.ListProjects())
{
...
}
Application fails at .EnsureAuthenticated() with exception:
TF400324: Team Foundation services are not available from server ...
A connection attempt failed because the connected party did not
properly respond after a period of time, or established connection
failed because connected host has failed to respond ...
It does work from another subnet where direct access to the TFS server is allowed.
QUESTION:
How can I use HTTP proxy in my C# application for connection to TFS?

Try adding an App.config file to set the default proxy with the following code:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<system.net>
<defaultProxy enabled="true" useDefaultCredentials="true"></defaultProxy>
</system.net>
</configuration>

You can directly set credentials to pass the proxy:
WebProxy p = new WebProxy("proxyserver.domain.com:8080", true);
p.Credentials = new NetworkCredential("domain\\user", "password");
WebRequest.DefaultWebProxy = p;
In my scenario we have a subnet for development and those accounts/machines are not allowed to access the internet. Therefore we need to enter the upper domain proxy and those domain credentials to get access to internet.

WCF error "no endpoint listening" with named pipes

I'm using WCF with .NET 3.5 I am using named pipes but keep getting the error
There was no endpoint listening at
net.pipe://localhost/Test that could
accept the message. This is often
caused by an incorrect address or SOAP
action.
I followed the tutorial http://www.switchonthecode.com/tutorials/wcf-tutorial-basic-interprocess-communication but the problem remains. The endpoints on both the client and server are the same (I checked spelling etc). There is no config file for this project but the config is in the code.
EDIT: Code (client):
ChannelFactory<ITest> pipeFactory =
new ChannelFactory<ITest>(
new NetNamedPipeBinding(),
new EndpointAddress(
"net.pipe://localhost/test"));
ITest test= pipeFactory.CreateChannel();
test.doStuff();
SERVER:
serviceHost = new ServiceHost(typeof(Test), new Uri("net.pipe://localhost"));
serviceHost.AddServiceEndpoint(typeof(ITest), new NetNamedPipeBinding(), "test");
File.Create(#"C:\test.txt");
serviceHost.Open();
Thanks

On the server side don't include base addresses when you create the ServiceHost instance. Instead, provide the fully qualified endpoint address when you add the service endpoint:
serviceHost = new ServiceHost(typeof(Test));
serviceHost.AddServiceEndpoint(typeof(ITest), new NetNamedPipeBinding(), new EndpointAddress("net.pipe://localhost/test"));
File.Create(#"C:\\test.txt");
serviceHost.Open();

This could be:
You are running it as a windows service and the service is not running
You are running it as a console app and there is no console.readline, so it just exists
You are running client and server on two different machines so that localhost is not going to the machine with the service.

Another possibility to fix this root issue if you are getting an error that no net.pipe address can be found at your url (i.e. http://localhost:1234/MyService/etc/) is to make sure that the Net.Pipe Listener Adapter Windows Service is started. (I also started Net.Tcp Listener Adapter)
The service does not seem to be enabled or started in some scenarios especially when deploying out to a remote server that might not of had a lot of the development tools installed that actively use these services. Starting the service fixed the issue.