We Keep Coding

How to fix UPDATE_APP_TO_LOGIN error in TLSharp C#

Hi i am using TLSharp latest version is 0.1.0.574 and when i call var hash = await client.SendCodeRequestAsync("<my_phone>"); i got error System.InvalidOperationException: 'UPDATE_APP_TO_LOGIN' anyone know how to fix it
My code
TelegramClient client = new TelegramClient(appid, "apihash",null,"session",null,DataCenterIPVersion.OnlyIPv4);
await client.ConnectAsync();
var hash = await client.SendCodeRequestAsync("<my_phone>");
string code = "";
await client.SignUpAsync("<my_phone>", hash, code, "<fist_name>", "last_name");

The error "UPDATE_APP_TO_LOGIN" happens because your Telegram Client/Library uses an obsolete API layer.
As stated on its project page, TLSharp is no longer maintained and will not be updated to fix this.
You should switch to WTelegramClient which is:
offering up-to-date API (latest layer)
safer (latest MTProto v2 implementation and many security checks)
feature-complete (covers all API methods, handling of updates, multiple-DC connections)
easy-to-use (API calls are direct methods with fully documented parameters in VS)
designed for .NET 5.0+, but also available for .NET Standard 2.0 (.NET Framework 4.6.1+ & .NET Core 2.0+)
Available on Nuget. ReadMe/Github is here.

How to use tsl version 1.0 in C# server?

Welcome, Im interesting in creating my own local service, witch support TSL v1 only.
I know its weak. But some app does not allow use modern cert above 1.0...
This app has no update to long, and just update it to TSL 1.3/1.2 is impossible.
There two question in complex.
How to create self-signed cert (private and public key) v1.0
How to use this cert in C#, im binding loop back address.
maybe soft like makecert/openssl can help? Which crypt-algorithm i should to use?

This answer is for .NET Core 2.0 and above.
This guide Kestrel web server implementation in ASP.NET Core, it is a guide to create a server.
The certificate and TLS version can be configured in Kestrel server HTTPS defauls:
app.ConfigureKestrel(serverOptions =>
{
serverOptions.ConfigureHttpsDefaults(listenOptions =>
{
listenOptions.SslProtocols = SslProtocols.Tls;
listenOptions.ServerCertificate = x509Certificate2; // instance of X509Certificate2
});
});
The value SslProtocols.Tls specifies TLS 1.0 security protocol.
How to create a valid, self-signed, X509Certificate2, needed in the code above, is described here. Certificates API was added to .Net Core on 2.0 version.

"The request was aborted: Could not create SSL/TLS secure channel"

Sometimes my client is getting an error during the payment process:
The request was aborted: Could not create SSL/TLS secure channel.
Authorize.NET has been used for the payment system. .Net 4.0 Framework is being used. This error is occurring sometimes, why?

Please try this suggested answer on github to https://github.com/AuthorizeNet/sdk-dotnet/issues/203:
using System.Security.Authentication;
using System.Net
// Prior to your web request ...
const SslProtocols _Tls12 = (SslProtocols)0x00000C00;
const SecurityProtocolType Tls12 = (SecurityProtocolType)_Tls12;
ServicePointManager.SecurityProtocol = Tls12;
(Comment by NexWeb.)

This is happening due to invalid version of .NET Braintree SDK.
You need to update the .NET Braintree SDK you're using to at least version 3.1.0, the minimum version that supports TLS 1.2. Once complete, you can validate your setup using the steps here.
Also, you need to update the .net version from 4.0 to 4.5
For more information, check this link.

Sending an email with SendGrid API from ASP.Net Framework 3.5

I'm trying to send an email using SendGrid API with an API Key I already have.
The problem is: I have to do this from an old .net application, whose asp.net framework version is 3.5 (and changing framework version is not an option)
I'm failing to find useful information on how to achieve it. The only code I found makes use of SendGrid csharp libraries, and these do not support asp.net framework 3.5
This is the code sample I found here, but I cannot make this work from my .net 3.5 web app:
// using SendGrid's C# Library - https://github.com/sendgrid/sendgrid-csharp
using System.Net.Http;
using System.Net.Mail;
var myMessage = new SendGrid.SendGridMessage();
myMessage.AddTo("test#sendgrid.com");
myMessage.From = new MailAddress("you#youremail.com", "First Last");
myMessage.Subject = "Sending with SendGrid is Fun";
myMessage.Text = "and easy to do anywhere, even with C#";
var transportWeb = new SendGrid.Web("SENDGRID_APIKEY");
transportWeb.DeliverAsync(myMessage);
// NOTE: If you're developing a Console Application, use the following so that the API call has time to complete
// transportWeb.DeliverAsync(myMessage).Wait();
Any ideas?

You have a couple of options. The SendGrid API uses the HttpClient class to make the requests and this requires the .NET 4+ dependency.
You could try implementing your own implementation using RestSharp, this is compatible with .NET 3.5 and the SendGrid API uses an interface you can implement. It would just need to be adjusted from the source code on github.
Use the .Net SMTP classes to send your emails and configure as per the guidelines in the SendGrid documentation.
Proxy the requests via another WebAPI that is running .NET 4+ and simplify what is required to make these calls by implementing your own API. Use something like the WebClient class or RestSharp to make the calls.
** Scrap that, option 1 is harder than it looked **
That the ISendGridClient is a bit of a weird example. It used the implementation inside of the interface for some parameters. Looks like 2 and 3 are good options!

Which versions of SSL/TLS does System.Net.WebRequest support?

Now that SSL 3 has been found to be vulnerable to the POODLE attack:
Which versions of SSL/TLS does System.Net.WebRequest use when connecting to any https Uri?
I use WebRequest to connect to several 3rd party API's. One of these has now said they will block any request that uses SSL 3. But WebRequest is part of the .Net core framework (using 4.5) so it is not obvious what version it uses.

This is an important question. The SSL 3 protocol (1996) is irreparably broken by the Poodle attack published 2014. The IETF have published "SSLv3 MUST NOT be used". Web browsers are ditching it. Mozilla Firefox and Google Chrome have already done so.
Two excellent tools for checking protocol support in browsers are SSL Lab's client test and https://www.howsmyssl.com/ . The latter does not require Javascript, so you can try it from .NET's HttpClient:
// set proxy if you need to
// WebRequest.DefaultWebProxy = new WebProxy("http://localhost:3128");
File.WriteAllText("howsmyssl-httpclient.html", new HttpClient().GetStringAsync("https://www.howsmyssl.com").Result);
// alternative using WebClient for older framework versions
// new WebClient().DownloadFile("https://www.howsmyssl.com/", "howsmyssl-webclient.html");
The result is damning:
Your client is using TLS 1.0, which is very old, possibly susceptible to the BEAST attack, and doesn't have the best cipher suites available on it. Additions like AES-GCM, and SHA256 to replace MD5-SHA-1 are unavailable to a TLS 1.0 client as well as many more modern cipher suites.
That's concerning. It's comparable to 2006's Internet Explorer 7.
To list exactly which protocols a HTTP client supports, you can try the version-specific test servers below:
var test_servers = new Dictionary<string, string>();
test_servers["SSL 2"] = "https://www.ssllabs.com:10200";
test_servers["SSL 3"] = "https://www.ssllabs.com:10300";
test_servers["TLS 1.0"] = "https://www.ssllabs.com:10301";
test_servers["TLS 1.1"] = "https://www.ssllabs.com:10302";
test_servers["TLS 1.2"] = "https://www.ssllabs.com:10303";
var supported = new Func<string, bool>(url =>
{
try { return new HttpClient().GetAsync(url).Result.IsSuccessStatusCode; }
catch { return false; }
});
var supported_protocols = test_servers.Where(server => supported(server.Value));
Console.WriteLine(string.Join(", ", supported_protocols.Select(x => x.Key)));
I'm using .NET Framework 4.6.2. I found HttpClient supports only SSL 3 and TLS 1.0. That's concerning. This is comparable to 2006's Internet Explorer 7.
Update: It turns HttpClient does support TLS 1.1 and 1.2, but you have to turn them on manually at System.Net.ServicePointManager.SecurityProtocol. See https://stackoverflow.com/a/26392698/284795
I don't know why it uses bad protocols out-the-box. That seems a poor setup choice, tantamount to a major security bug (I bet plenty of applications don't change the default). How can we report it?

When using System.Net.WebRequest your application will negotiate with the server to determine the highest TLS version that both your application and the server support, and use this. You can see more details on how this works here:
http://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_handshake
If the server doesn't support TLS it will fallback to SSL, therefore it could potentially fallback to SSL3. You can see all of the versions that .NET 4.5 supports here:
http://msdn.microsoft.com/en-us/library/system.security.authentication.sslprotocols(v=vs.110).aspx
In order to prevent your application being vulnerable to POODLE, you can disable SSL3 on the machine that your application is running on by following this explanation:
https://serverfault.com/questions/637207/on-iis-how-do-i-patch-the-ssl-3-0-poodle-vulnerability-cve-2014-3566

I also put an answer there, but the article #Colonel Panic's update refers to suggests forcing TLS 1.2. In the future, when TLS 1.2 is compromised or just superceded, having your code stuck to TLS 1.2 will be considered a deficiency. Negotiation to TLS1.2 is enabled in .Net 4.6 by default. If you have the option to upgrade your source to .Net 4.6, I would highly recommend that change over forcing TLS 1.2.
If you do force TLS 1.2, strongly consider leaving some type of breadcrumb that will remove that force if you do upgrade to the 4.6 or higher framework.