Bu yazıda hem ax 2009 hemde ax 2012 de TLS 1.2 gibi güncel güvenlik protokolünü destekleyen web servislere nasıl erişebileceğimizden bahsedeceğim. Bir sunucu sadece TLS 1.2 destekliyorsa ax içinden bir istek gönderdiğinizde aşağıdaki hata ile karşılaşırsınız.
The underlying connection was closed: An unexpected error occurred on a send. Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host. An existing connection was forcibly closed by the remote host.
TLS 1.0 protokolünün açıkları olduğu için bazı sunucular direkt olarak bloklamakta. Bu hatayı giderebilmek için, ax içinden sunucuya istekte bulunurken güvenlik protokolünü sunucunun desteklediği TLS sürümü olarak ayarlamak gerekiyor. Buda genellikle 1.1 yada 1.2 olmakta.
Bir Sitenin Desteklediği TLS Versiyonunu Öğrenme
Bir sitenin hangi güvenlik protokollerini desteklediğini görmek için bu adresteki servisi kullanabilirsiniz.
Örneğin:
google.com – tüm TLS sürümlerini destekliyor.
incapsula.com – sadece TLS 1.2 destekliyor.
Bu sorunu giderebilmek için ax sürümlerine göre farklı aksiyonlar almamız gerekiyor. Burada kilit nokta aşağıdaki belirttiğim kod parçacığı. Bu çalıştıktan sonra yapılacak olan tüm requestlerde .NET’in kullandığı varsayılan TLS versiyonunu 1.2 yapıyoruz.
System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12 | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls;
AX 2009 için
Ax 2009 .NET 3.5 kullanıyor. Ve bu sürümde sadece SSL 3 ve TLS 1.0 kullanabiliyorsunuz. TLS 1.2 isteyen bir siteye erişmek yapabileceğiniz en iyi yöntem .Net 4.0 veya üstünü kullanan bir asmx web servis yazıp bunu ax 2009 içinde çağırmak olacaktır. Web servisde ise aşağıda verdiğim örnek kodu kullanabilirsiniz.
Örnek kod .NET Framework’ün en güncel yöntemi olan HttpClient‘ı kullanıyor. Bu kütüphaneyi kullanabilmek asmx servisin versiyonu .NET Framework 4.5+ olmalı. 4.0 versiyonu için bu linkte yer alan WebRequest vb. legacy yöntemler ile sorguyu güncelleyebilirsiniz. Burada önemli nokta SecurityProtocol ataması yaptığımız bölümün aynen kalması gerekiyor.
// Güven Şahin - guvensahin.com
public HttpResponseMessage GetProductImages()
{
try
{
string ret = String.Empty;
string url = ""; // istek yapılacak url yazılmalı
using (var client = new HttpClient())
{
// istek yaparken TLS 1.2'yi varsayılan güvenlik protokolü olarak atıyoruz
System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12 | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls;
client.Timeout = new TimeSpan(0, 2, 0); // 2 min
try
{
var response = client.GetAsync(url).Result;
if (response.IsSuccessStatusCode)
{
ret = response.Content.ReadAsStringAsync().Result;
}
else
{
var msg = "url: " + url + "\n"
+ "StatusCode: " + response.StatusCode.ToString() + "\n"
+ "ReasonPhrase: " + response.ReasonPhrase;
throw new Exception(msg);
}
}
finally
{
client.Dispose();
}
}
return Request.CreateResponse(HttpStatusCode.OK, ret);
}
catch (Exception ex)
{
return Request.CreateResponse(HttpStatusCode.InternalServerError, ex);
}
}
AX 2012 için
AX 2012 .NET 4.0 kullandığı için .NET’te geçerli olan SecurityProtocol komutunu direkt ax içinden çağırabiliyoruz. Aşağıdaki örnek job’ı kullanarak TLS 1.2 destekli bir siteye direkt istekte bulunabilirsiniz. SecurityProtocol ataması yapan kısmı commentleyip denerseniz TLS 1.0’a döneceği için yazının başında belirttiğim hatayı alacaksınız.
// Güven Şahin - guvensahin.com
static void GVNWebClientTestTLS12(Args _args)
{
System.Net.WebClient webClient;
str content;
;
new InteropPermission(InteropKind::CLRInterop).assert();
try
{
System.Net.ServicePointManager::set_SecurityProtocol(System.Net.SecurityProtocolType::Tls12);
webClient = new System.Net.WebClient();
content = @webClient.DownloadString("https://www.incapsula.com/");
info(content);
}
catch (Exception::CLRError)
{
throw error(AifUtil::getClrErrorMessage());
}
CodeAccessPermission::revertAssert();
}
Sonraki yazılarda görüşmek üzere,
Hoşçakalın.
Elinize sağlık. Teşekkürler
Kod içinde TLS versiyonu belirtilmediğinde 1.0 üzerinden haberleşme sağlanıyor. OpenSSL de ortaya çıkan kritik açıktan sonra web üzerinden hizmet veren sağlayıcılar güncellemelere gittikçe bu açık entegrasyon projelerini patlatacaktır, güzel konu,
Geçen ay hizmet aldığımız servis sağlayıcının uyarısıyla bizde benzer bir çalışma yapmıştık.