Schannel

Kimlik doğrulama hizmeti tanımlayıcısı RPC_C_AUTHN_GSS_SCHANNEL olan Güvenli Kanal (Schannel) güvenlik paketi şu ortak anahtar tabanlı protokolleri destekler: SSL (Güvenli Yuva Katmanı) sürüm 2.0 ve 3.0, Aktarım Katmanı Güvenliği (TLS) 1.0 ve Özel İletişim Teknolojisi (PCT) 1.0. TLS 1.0, Internet Engineering Task Force (IETF) tarafından Ocak 1999'da RFC 2246 belgesinde yayımlanan, standartlaştırılmış, biraz değiştirilmiş bir SSL 3.0 sürümüdür. TLS standartlaştırıldığından, geliştiricilerin SSL yerine TLS kullanması önerilir. PCT yalnızca geriye dönük uyumluluk için dahil edilir ve yeni geliştirme için kullanılmamalıdır. Schannel güvenlik paketi kullanıldığında DCOM, istemci ve sunucu özelliklerine bağlı olarak en iyi protokolü otomatik olarak görüşür.

Aşağıdaki konularda TLS protokolü ve DCOM ile nasıl çalıştığı kısaca açıklanmaktadır.

TLS Ne Zaman Kullanılır?
TLS'nin Nasıl Çalıştığına Kısa Genel Bakış
X.509 Sertifikaları
- İstemci Sertifikaları
COM'da TLS kullanma
İlgili konular

Uyarı

Bu bölümlerdeki TLS protokolü hakkındaki tüm bilgiler SSL ve PCT protokolleri için de geçerlidir.

TLS Ne Zaman Kullanılır?

TLS, sunucuların anonim istemcilere kimliklerini kanıtlaması gerektiğinde kullanılabilen tek güvenlik seçeneğidir. Bu özellikle e-ticarete katılmak isteyen web siteleri için önemlidir çünkü kredi kartı numaraları gibi hassas bilgilerin iletiminin korunmasına yardımcı olur. TLS, e-ticaret müşterilerine sunucunun kimliğinin kanıtı verildiğinden, kiminle iş yaptıkları konusunda emin olabileceklerini garanti eder. Ayrıca e-ticaret sunucusuna her bir müşterisinin kimliğini doğrulamakla ilgilenmek zorunda kalmadan verimlilik sağlar.

TLS, tüm sunucuların istemcilere kimliklerini kanıtlamasını gerektirir. Ayrıca TLS, istemcilerin sunuculara kimliklerini kanıtlamasını sağlama seçeneği sunar. Bu karşılıklı kimlik doğrulaması, büyük bir şirket intranetindeki belirli web sayfalarının erişimini kısıtlamada yararlı olabilir.

TLS, en güçlü kimlik doğrulama düzeylerini destekler ve teknolojik yeniliklere ayak uydurmak için şifreleme gücünün zaman içinde artmasına izin veren açık bir mimari sunar. TLS, aktarımdaki veriler için en yüksek güvenlik düzeyinin istendiği ortamlar için en iyi seçimdir.

TLS'nin Nasıl Çalıştığına Kısa Genel Bakış

TLS, veri şifrelemeyi etkinleştirmek ve veri bütünlüğünü sağlamak için ortak/özel anahtar çiftlerini kullanan ve kimlik doğrulaması için X.509 sertifikalarını kullanan bir ortak anahtar altyapısı (PKI) üzerine kurulmuştur.

Kerberos v5 protokolü gibi birçok güvenlik protokolü, verileri şifrelemek ve şifresini çözmek için tek bir anahtara bağlıdır. Bu nedenle bu tür protokoller şifreleme anahtarlarının güvenli değişimine bağlıdır; Bu, Kerberos protokolünde Anahtar Dağıtım Merkezi'nden (KDC) alınan biletler aracılığıyla yapılır. Bu, Kerberos protokolünün kullanıldığı herkesin KDC'ye kaydedilmesini gerektirir. Bu, dünyanın dört bir yanından milyonlarca müşteriyi çekmeyi amaçlayan bir e-ticaret web sunucusu için pratik olmayan bir sınırlama olacaktır. Bu nedenle TLS, veri şifrelemesi için iki anahtar kullanan bir PKI'ya dayanır; çiftin bir anahtarı verileri şifrelediğinde, çiftin yalnızca diğer anahtarı şifrelerini çözebilir. Bu tasarımın temel avantajı, şifreleme anahtarlarının güvenli değişimine gerek kalmadan şifrelemenin gerçekleştirilebiliyor olmasıdır.

PKI, anahtarlardan birinin özel tutulduğu ve yalnızca kayıtlı olduğu sorumlu tarafından kullanılabildiği, diğer anahtarın ise herkesin erişmesi için ortak hale getirildiği bir teknik kullanır. Birisi bir anahtar çiftinin sahibine özel ileti göndermek isterse, ileti ortak anahtarla şifrelenebilir ve iletinin şifresini çözmek için yalnızca özel anahtar kullanılabilir.

Anahtar çiftleri, gönderilen verilerin bütünlüğünü doğrulamak için de kullanılır. Bunu yapmak için anahtar çiftinin sahibi, göndermeden önce verilere dijital imza ekleyebilir. Dijital imza oluşturmak için verilerin karması hesaplanır ve karma özel anahtarla şifrelenir. Dijital imzanın şifresini çözmek için ortak anahtarı kullanan herkes, dijital imzanın yalnızca özel anahtarın sahibi olan kişiden gelmiş olması gerektiğinden emin olur. Buna ek olarak, alıcı gönderenle aynı algoritmayı kullanarak verilerin karması hesaplayabilir ve hesaplanan karma dijital imzada gönderilen karmayla eşleşiyorsa, alıcı verilerin dijital olarak imzalandıktan sonra değiştirilmediğinden emin olabilir.

Yüksek hacimli veri şifrelemesi için PKI kullanmanın bir dezavantajı, görece yavaş performansıdır. Söz konusu yoğun matematik nedeniyle, bir anahtar çiftine bağlı olan asimetrik bir şifreleme kullanarak verilerin şifrelenmesinin ve şifresinin çözülmesi, yalnızca tek bir anahtara bağlı olan bir simetrik şifreleme kullanarak şifreleme ve şifre çözmeden 1.000 kat daha yavaş olabilir. Bu nedenle TLS, PKI'yı yalnızca dijital imzalar oluşturmak ve hem istemci hem de sunucu tarafından toplu veri şifrelemesi ve şifre çözme için kullanılacak oturuma özgü tek anahtar anlaşması için kullanır. TLS çok çeşitli tek anahtarlı simetrik şifrelemeleri destekler ve gelecekte ek şifrelemeler eklenebilir.

TLS el sıkışma protokolü hakkında daha fazla bilgi için bkz. TLS El Sıkışma Protokolü.

TLS protokolunun arkasındaki şifrelemeyle ilgili daha fazla bilgi için bkz . Şifreleme Temel Bileşenleri.

X.509 Sertifikaları

PKI tarafından işlenmesi gereken kritik bir sorun, kullanılan ortak anahtarın orijinalliğine güvenebilme özelliğidir. İş yapmak istediğiniz bir şirkete verilen ortak anahtarı kullandığınızda, kredi kartı numaranızı bulmak isteyen bir hırsız yerine anahtarın gerçekten şirkete ait olduğundan emin olmak istersiniz.

Anahtar çifti olan bir sorumlunun kimliğini garanti etmek için, sorumluya bir sertifika yetkilisi (CA) tarafından bir X.509 sertifikası verilir. Bu sertifika, sorumluyu tanımlayan, sorumlunun ortak anahtarını içeren ve CA tarafından dijital olarak imzalanan bilgileri içerir. Bu dijital imza, CA'nın sertifikada bulunan ortak anahtarın sertifika tarafından tanımlanan sorumluya ait olduğuna inandığını gösterir.

Ca'ya nasıl güvenirsiniz? CA'nın kendisi, daha üst düzey bir CA tarafından imzalanmış bir X.509 sertifikasına sahip olduğundan. Bu sertifika imza zinciri, kendi sertifikalarını imzalayan bir CA olan kök CA'ya ulaşana kadar devam eder. Bir sertifikanın kök CA'sının bütünlüğüne güveniyorsanız, sertifikanın özgünlüğüne güvenebilmeniz gerekir. Bu nedenle, güvenmek istediğiniz kök CA'ları seçmek sistem yöneticisi için önemli bir görevdir.

İstemci Sertifikaları

Güvenlik aktarım katmanı protokolleri ilk kez ortaya çıktığında, birincil amaçları bir istemcinin gerçek bir sunucuya bağlandığını garanti etmek ve aktarım sırasında verilerin gizliliğini korumaya yardımcı olmaktı. Ancak SSL 3.0 ve TLS 1.0, protokolün el sıkışması sırasında istemci sertifikasının iletilmesi için de destek içerir. Bu isteğe bağlı özellik, istemci ve sunucunun karşılıklı kimlik doğrulamasını etkinleştirir.

İstemci sertifikasının kullanılıp kullanılmayacağı kararı uygulama bağlamında verilmelidir. Birincil gereksinim sunucunun kimliğini doğrulamaksa istemci sertifikaları gereksizdir. Ancak, istemci kimlik doğrulaması gerekliyse, uygulama içinde özel kimlik doğrulaması kullanmak yerine istemcinin sertifikası kullanılabilir. Kullanıcılara çoklu oturum açma senaryosu sağladığından, istemci sertifikalarının kullanılması özel kimlik doğrulaması yerine tercih edilir.

COM'da TLS kullanma

TLS yalnızca kimliğe bürünme (RPC_C_IMP_LEVEL_IMPERSONATE) düzeyini destekler. COM bir proxy'de kimlik doğrulama hizmeti olarak TLS anlaşması yaparsanız, COM işlem varsayılanı ne olursa olsun kimliğe bürünme düzeyini kimliğe bürünecek şekilde ayarlar. Kimliğe bürünme özelliğinin TLS'de düzgün çalışması için istemcinin sunucuya bir X.509 sertifikası sağlaması ve bu sertifikanın sunucudaki belirli bir kullanıcı hesabına eşlenmiş olması gerekir. Daha fazla bilgi için bkz. Sertifikaları Kullanıcı Hesaplarına Eşlemek için Adım Adım Kılavuz.

TLS gizlemeyi desteklemez. CoInitializeSecurity veya IClientSecurity::SetBlanket çağrısında bir gizleme bayrağı ve TLS belirtilirse, E_INVALIDARG döndürülür.

TLS, kimlik doğrulama düzeyi Yok olarak ayarlandığında çalışmaz. İstemci ve sunucu arasındaki el sıkışması, her birinin ayarladığı kimlik doğrulama düzeyini inceler ve bağlantı için daha yüksek güvenlik ayarını seçer.

TLS için güvenlik parametreleri CoInitializeSecurity ve CoSetProxyBlanket çağrılarak ayarlanabilir. Aşağıdaki bölümlerde bu çağrıları yaparken kullanılan nüanslar açıklanmaktadır.

Sunucu Güvenlik Battaniyesini Nasıl Ayarlar?

Bir sunucu TLS kullanmak istiyorsa, CoInitializeSecurity'ninasAuthSvc parametresinde kimlik doğrulama hizmeti olarak Schannel (RPC_C_AUTHN_GSS_SCHANNEL) belirtmelidir. İstemcilerin daha az güvenli bir kimlik doğrulama hizmeti kullanarak sunucuya bağlanmasını önlemek için, sunucu CoInitializeSecurity'yi çağırdığında kimlik doğrulama hizmeti olarak yalnızca Schannel'i belirtmelidir. Sunucu , CoInitializeSecurity adını verdikten sonra güvenlik battaniyesini değiştiremez.

TLS kullanmak için, bir sunucu CoInitializeSecurity'yi çağırdığında aşağıdaki parametreler belirtilmelidir:

pVoid , IAccessControl nesnesinin işaretçisi veya SECURITY_DESCRIPTOR işaretçisi olmalıdır. NULL veya AppID işaretçisi olmamalıdır.
cAuthSvc 0 veya -1 olamaz. cAuthSvc-1 olduğunda COM sunucuları hiçbir zaman Schannel'i seçmez.
asAuthSvc , schannel'i olası bir kimlik doğrulama hizmeti olarak belirtmelidir. Bu, SOLE_AUTHENTICATION_LIST Schannel üyesi için aşağıdaki SOLE_AUTHENTICATION_SERVICE parametreleri ayarlanarak yapılır:
- dwAuthnSvc RPC_C_AUTHN_GSS_SCHANNEL olmalıdır.
- dwAuthzSvc RPC_C_AUTHZ_NONE olmalıdır. Şu anda yok sayılır.
- pPrincipalName , sunucunun X.509 sertifikasını temsil eden OLECHAR işaretçisi olarak atan bir CERT_CONTEXT işaretçisi olmalıdır.
dwAuthnLevel , başarılı bir bağlantı için istemcilerden kabul edilecek en düşük kimlik doğrulama düzeyini gösterir. RPC_C_AUTHN_LEVEL_NONE olamaz.
dwCapabilities'de EOAC_APPID bayrağı ayarlanmamalıdır. pVoid bir IAccessControl nesnesine işaret ederse EOAC_ACCESS_CONTROL bayrağı ayarlanmalıdır; pVoid bir SECURITY_DESCRIPTOR işaret ederse ayarlanmamalıdır. Ayarlanabilecek diğer bayraklar için bkz. CoInitializeSecurity.

CoInitializeSecurity kullanma hakkında daha fazla bilgi için bkz. CoInitializeSecurity ile İşlem Genelinde Güvenliği Ayarlama.

İstemci Güvenlik Battaniyesini Nasıl Ayarlar?

bir istemci TLS kullanmak istiyorsa, CoInitializeSecuritypAuthList parametresinde kimlik doğrulama hizmetleri listesinde Schannel (RPC_C_AUTHN_GSS_SCHANNEL) belirtmelidir. CoInitializeSecurity çağrıldığında Schannel olası bir kimlik doğrulama hizmeti olarak belirtilmezse, kimlik doğrulama hizmeti olarak Schannel'i belirtmeye çalışırsa CoSetProxyBlanket'e (veya IClientSecurity::SetBlanket) sonraki bir çağrı başarısız olur.

İstemci CoInitializeSecurity'yi çağırdığında aşağıdaki parametreler belirtilmelidir:

dwAuthnLevel , istemcinin kullanmak istediği varsayılan kimlik doğrulama düzeyini belirtir. RPC_C_AUTHN_LEVEL_NONE olamaz.
dwImpLevel RPC_C_IMP_LEVEL_IMPERSONATE olmalıdır.
pAuthList , listenin bir üyesi olarak aşağıdaki SOLE_AUTHENTICATION_INFO parametrelerine sahip olmalıdır:
- dwAuthnSvc RPC_C_AUTHN_GSS_SCHANNEL olmalıdır.
- dwAuthzSvc RPC_C_AUTHZ_NONE olmalıdır.
- pAuthInfo, istemcinin X.509 sertifikasını temsil eden void işaretçisi olarak türeyen bir CERT_CONTEXT işaretçisidir. İstemcinin sertifikası yoksa veya sertifikasını sunucuya sunmak istemezse , pAuthInfoNULL olmalıdır ve sunucuyla anonim bir bağlantı denenir.
dwCapabilities , ek istemci özelliklerini gösteren bir bayrak kümesidir. Hangi bayrakların ayarlanması gerektiği hakkında bilgi için bkz. CoInitializeSecurity .

CoInitializeSecurity kullanma hakkında daha fazla bilgi için bkz. CoInitializeSecurity ile İşlem Genelinde Güvenliği Ayarlama.

İstemci Güvenlik Battaniyesini Nasıl Değiştirir?

bir istemci TLS kullanmak istiyor ancak CoInitializeSecurity çağrısından sonra güvenlik paketi değiştirmek istiyorsa, CoInitializeSecurity çağrısında kullanılanlara benzer parametrelerle CoSetProxyBlanket veya IClientSecurity::SetBlanket çağrısı yapmalıdır ve aşağıdaki farklarla:

pServerPrincName , sunucunun asıl adını msstd veya fullsic biçiminde gösterir. Bu biçimler hakkında bilgi için bkz. Asıl Adlar. İstemci sunucunun X.509 sertifikasına sahipse RpcCertGeneratePrincipalName çağırarak asıl adı bulabilir.
pAuthInfo , istemcinin X.509 sertifikasını temsil eden RPC_AUTH_IDENTITY_HANDLE işaretçisi olarak türeyen bir CERT_CONTEXT işaretçisidir. İstemcinin sertifikası yoksa veya sertifikasını sunucuya sunmak istemezse , pAuthInfoNULL olmalıdır ve sunucuyla anonim bir bağlantı denenir.
dwCapabilities , ek istemci özelliklerini gösteren bayraklardan oluşur. Güvenlik paket ayarlarını değiştirmek için yalnızca dört bayrak kullanılabilir: EOAC_DEFAULT, EOAC_MUTUAL_AUTH, EOAC_ANY_AUTHORITY (bu bayrak kullanım dışıdır) ve EOAC_MAKE_FULLSIC. Daha fazla bilgi için bkz. CoSetProxyBlanket.

CoSetProxyBlanket kullanma hakkında daha fazla bilgi için bkz. Arabirim Ara Sunucusu Düzeyinde Güvenliği Ayarlama.

Örnek: İstemci Güvenlik Battaniyesini Değiştirir

Aşağıdaki örnek, istemcinin X.509 sertifikasını sağlaması için sunucudan gelen bir isteği karşılamak üzere güvenlik paketinde nasıl değişiklik yapabileceğinizi gösterir. Kısa süre için hata işleme kodu atlanır.

void ClientChangesSecurity ()
{
  HCRYPTPROV                   provider           = 0;
  HCERTSTORE                   cert_store         = NULL;
  PCCERT_CONTEXT               client_cert        = NULL;
  PCCERT_CONTEXT               server_cert        = NULL;
  WCHAR                        *server_princ_name = NULL;
  ISecret                      *pSecret           = NULL;
  MULTI_QI                     server_instance;
  COSERVERINFO                 server_machine;
  SOLE_AUTHENTICATION_LIST     auth_list;
  SOLE_AUTHENTICATION_INFO     auth_info[1];



  // Specify all the authentication info. 
  // The client is willing to connect using SChannel,
  //   with no client certificate.
  auth_list.cAuthInfo     = 1;
  auth_list.aAuthInfo     = auth_info;
  auth_info[0].dwAuthnSvc = RPC_C_AUTHN_GSS_SCHANNEL;
  auth_info[0].dwAuthzSvc = RPC_C_AUTHZ_NONE;
  auth_info[0].pAuthInfo  = NULL;  // No certificate

  // Initialize client security with no client certificate.
  CoInitializeSecurity( NULL, -1, NULL, NULL,
                        RPC_C_AUTHN_LEVEL_PKT,
                        RPC_C_IMP_LEVEL_IMPERSONATE, &auth_list,
                        EOAC_NONE, NULL );
  
  // Specify info for the proxy.
  server_instance = {&IID_ISecret, NULL, S_OK};
  server_machine  = {0, L"ServerMachineName", NULL, 0};
  
  // Create a proxy.
  CoCreateInstanceEx( CLSID_Secret, NULL, CLSCTX_REMOTE_SERVER, 
                      &server_machine, 1, &server_instance);
  pSecret = (ISecret *) server_instance.pItf;

  //** The client obtained the server's certificate during the handshake.
  //** The server requests a certificate from the client.

  // Get the default certificate provider.
  CryptAcquireContext( &provider, NULL, NULL, PROV_RSA_SCHANNEL, 0 );

  // Open the certificate store.
  cert_store = CertOpenSystemStore( provider, L"my" );

  // Find the client's certificate.
  client_cert = 
    CertFindCertificateInStore( cert_store,
                                X509_ASN_ENCODING | PKCS_7_ASN_ENCODING,
                                0,
                                CERT_FIND_SUBJECT_STR,
                                L"ClientName",  // Use the principal name
                                NULL );

  // Find the fullsic principal name of the server.
  RpcCertGeneratePrincipalName( server_cert, RPC_C_FULL_CERT_CHAIN, 
                                &server_princ_name );

  // Change the client's security: 
  // Increase the authentication level and attach a certificate.
  CoSetProxyBlanket( pSecret, RPC_C_AUTHN_GSS_SCHANNEL,
                     RPC_C_AUTHZ_NONE,
                     server_princ_name, RPC_C_AUTHN_LEVEL_PKT_PRIVACY,
                     RPC_C_IMP_LEVEL_IMPERSONATE, 
                     (RPC_AUTH_IDENTITY_HANDLE *) client_cert,
                     EOAC_NONE );

  cleanup:
  if (server_princ_name != NULL)
    RpcStringFree( &server_princ_name );
  if (client_cert != NULL)
    CertFreeCertificateContext(client_cert);
  if (server_cert != NULL)
    CertFreeCertificateContext(server_cert);
  if (cert_store != NULL)
    CertCloseStore( cert_store, CERT_CLOSE_STORE_CHECK_FLAG );
  if (provider != 0 )
    CryptReleaseContext( provider, 0 );
  if (pSecret != NULL)
    pSecret->Release();
  CoUninitialize();
}

COM ve Güvenlik Paketleri

Geri Bildirim

Bu sayfayı yararlı buldunuz mu?

Last updated on 2026-04-15