Schannel

Balíček zabezpečení Schannel (Secure Channel), jehož identifikátor ověřovací služby je RPC_C_AUTHN_GSS_SCHANNEL, podporuje následující protokoly založené na veřejném klíči: SSL (Secure Sockets Layer) verze 2.0 a 3.0, TLS (Transport Layer Security) 1.0 a PRIVATE Communication Technology (PCT) 1.0. TLS 1.0 je standardizovaná, mírně upravená verze SSL 3.0, která byla vydána Internet Engineering Task Force (IETF) v lednu 1999 v dokumentu RFC 2246. Vzhledem k tomu, že protokol TLS je standardizovaný, vývojářům se doporučuje používat protokol TLS místo SSL. PCT je součástí pouze zpětné kompatibility a neměl by se používat pro nový vývoj. Při použití balíčku zabezpečení Schannel DCOM automaticky vyjedná nejlepší protokol v závislosti na možnostech klienta a serveru.

Následující témata stručně popisují protokol TLS a jeho fungování s modelem DCOM.

• Kdy používat protokol TLS
• stručný přehled fungování protokolu TLS
• certifikáty X.509
  • klientských certifikátů
• použití protokolu TLS v modelu COM
  • , jak server nastaví zabezpečení
  • jak klient nastaví zabezpečení
  • , jak klient změní bezpečnostní
  • Příklad : Klient změní zabezpečení
• související témata

Poznámka

Všechny informace o protokolu TLS v těchto částech platí také pro protokoly SSL a PCT.

 

Kdy použít protokol TLS

Protokol TLS je jedinou dostupnou možností zabezpečení, pokud servery potřebují prokázat svou identitu anonymním klientům. To je zvlášť důležité pro weby, které se chtějí účastnit elektronického obchodování, protože pomáhá chránit přenos citlivých informací, jako jsou čísla platebních karet. Protokol TLS zajišťuje, že zákazníci elektronického obchodování můžou být jistí, s kým obchodují, protože jim jsou uděleny doklady o identitě serveru. Poskytuje také serveru elektronického obchodování efektivitu, že se nemusí zabývat ověřováním identity každého zákazníka.

Protokol TLS vyžaduje, aby všechny servery prokázaly svou identitu klientům. Kromě toho protokol TLS poskytuje možnost, že klienti potvrdí svou identitu na serverech. Toto vzájemné ověřování může být užitečné při omezení přístupu určitých webových stránek ve velkém podnikovém intranetu.

PROTOKOL TLS podporuje nejsilnější úrovně ověřování a nabízí otevřenou architekturu, která umožňuje zvýšit sílu šifrování v průběhu času, aby se udržely v souladu s technologickými inovacemi. Protokol TLS je nejlepší volbou pro prostředí, kde je pro přenášená data požadovaná nejvyšší úroveň zabezpečení.

Stručný přehled fungování protokolu TLS

Protokol TLS je založený na infrastruktuře veřejných klíčů (PKI), která používá páry veřejného a privátního klíče k povolení šifrování dat a navazování integrity dat a k ověřování používá certifikáty X.509.

Mnoho protokolů zabezpečení, jako je protokol Kerberos v5, závisí na jednom klíči pro šifrování i dešifrování dat. Tyto protokoly proto závisejí na zabezpečené výměně šifrovacích klíčů; v protokolu Kerberos se to provádí prostřednictvím lístků získaných z centra distribuce klíčů (KDC). To vyžaduje, aby všichni používající protokol Kerberos byli zaregistrováni v KDC, což by bylo nepraktické omezení webového serveru elektronického obchodování, který má přilákat miliony zákazníků z celého světa. Protokol TLS proto spoléhá na pkI, který používá dva klíče pro šifrování dat", když jeden klíč páru šifruje data, může je dešifrovat pouze druhý klíč páru. Hlavní výhodou tohoto návrhu je, že šifrování je možné provádět bez nutnosti zabezpečené výměny šifrovacích klíčů.

Infrastruktura veřejných klíčů používá techniku, kdy je jeden z klíčů soukromý a je k dispozici pouze pro objekt zabezpečení, kterému je zaregistrovaný, zatímco druhý klíč se zpřístupní všem uživatelům, kteří k němu mají přístup. Pokud chce někdo poslat soukromou zprávu vlastníkovi páru klíčů, může být zpráva zašifrovaná pomocí veřejného klíče a k dešifrování zprávy se dá použít jenom soukromý klíč.

Páry klíčů se také používají k ověření integrity odesílaných dat. K tomu může vlastník páru klíčů před odesláním připojit digitální podpis k datům. Vytvoření digitálního podpisu zahrnuje výpočet hodnoty hash dat a šifrování hodnoty hash pomocí privátního klíče. Každý, kdo používá veřejný klíč k dešifrování digitálního podpisu, je jisté, že digitální podpis musí pocházet pouze od osoby, která vlastní soukromý klíč. Kromě toho může příjemce vypočítat hodnotu hash dat pomocí stejného algoritmu jako odesílatel a pokud počítaná hodnota hash odpovídá hodnotě odeslané v digitálním podpisu, může příjemce mít jistotu, že data nebyla po digitálním podepsání změněna.

Nevýhodou použití infrastruktury veřejných klíčů pro šifrování dat s velkým objemem je jeho relativně nízký výkon. Z důvodu náročné matematiky může šifrování a dešifrování dat pomocí asymetrického šifry, která závisí na páru klíčů, až 1 000krát pomalejší než šifrování a dešifrování pomocí symetrické šifry, která závisí pouze na jednom klíči. Protokol TLS proto používá pkI pouze pro generování digitálních podpisů a pro vyjednávání jediného klíče specifického pro relaci, který bude klient i server používat k hromadnému šifrování a dešifrování dat. Protokol TLS podporuje širokou škálu symetrických šifer s jedním klíčem a v budoucnu je možné přidat další šifry.

Další informace o protokolu HANDShake protokolu TLS naleznete v tématu TLS Handshake Protocol.

Další podrobnosti týkající se kryptografie za protokolem TLS naleznete v tématu Cryptography Essentials.

Certifikáty X.509

Kritický problém, který musí zpracovat infrastruktura veřejných klíčů, je schopnost důvěřovat pravosti používaného veřejného klíče. Když použijete veřejný klíč vystavený společnosti, se kterou chcete podnikat, chcete mít jistotu, že klíč skutečně patří společnosti, a ne zloději, který chce zjistit číslo vaší platební karty.

Aby se zajistila identita objektu zabezpečení držícího pár klíčů, objekt zabezpečení je vystaven certifikát X.509 certifikační autoritou (CA). Tento certifikát obsahuje informace, které identifikují objekt zabezpečení, obsahují veřejný klíč objektu a jsou digitálně podepsané certifikační autoritou. Tento digitální podpis označuje, že certifikační autorita věří, že veřejný klíč obsažený v certifikátu skutečně patří k objektu zabezpečení identifikovanému certifikátem.

A jak certifikační autoritě důvěřujete? Protože samotná certifikační autorita obsahuje certifikát X.509 podepsaný certifikační autoritou vyšší úrovně. Tento řetěz podpisů certifikátů pokračuje, dokud nedosáhne kořenové certifikační autority, což je certifikační autorita, která podepíše vlastní certifikáty. Pokud důvěřujete integritě kořenové certifikační autority certifikátu, měli byste být schopni důvěřovat pravosti samotného certifikátu. Proto výběr kořenových certifikačních autorit, kterým jste ochotni důvěřovat, je důležitou povinností správce systému.

Klientské certifikáty

Když se poprvé objevily protokoly přenosové vrstvy zabezpečení, jejich primárním účelem bylo zaručit, že se klient připojuje k autentickému serveru a pomáhá chránit soukromí dat během přenosu. Protokoly SSL 3.0 a TLS 1.0 však také zahrnují podporu přenosu certifikátu klienta během metody handshake protokolu. Tato volitelná funkce umožňuje vzájemné ověřování klienta a serveru.

Rozhodnutí o použití klientského certifikátu by mělo být provedeno v kontextu aplikace. Klientské certifikáty nejsou nutné, pokud primární požadavek ověřuje server. Pokud je ale ověření klienta nezbytné, můžete použít certifikát klienta, a nespoléhat se na vlastní ověřování v rámci aplikace. Použití klientských certifikátů je vhodnější než vlastní ověřování, protože uživatelům poskytuje scénář jednotného přihlašování.

Použití protokolu TLS v modelu COM

Protokol TLS podporuje pouze úroveň zosobnění (RPC_C_IMP_LEVEL_IMPERSONATE). Pokud com vyjedná tls jako ověřovací službu na proxy serveru, com nastaví úroveň zosobnění tak, aby se zosobnění bez ohledu na výchozí proces. Aby zosobnění fungovalo správně v protokolu TLS, musí klient poskytnout serveru certifikát X.509 a server musí mít tento certifikát namapovaný na konkrétní uživatelský účet na serveru. Další informace najdete v podrobném průvodci mapováním certifikátů na uživatelské účty.

Protokol TLS nepodporuje maskování. Pokud je v CoInitializeSecurity nebo IClientSecurity::SetBlanket volání zadán příznak maskování a TLS, vrátí se E_INVALIDARG.

Protokol TLS nefunguje s úrovní ověřování nastavenou na Žádné. Handshake mezi klientem a serverem zkontroluje úroveň ověřování nastavenou každou z nich a zvolí vyšší nastavení zabezpečení pro připojení.

Parametry zabezpečení protokolu TLS lze nastavit voláním CoInitializeSecurity a CoSetProxyBlanket. Následující části popisují drobné odlišnosti, které jsou součástí těchto volání.

Jak server nastaví bezpečnostní deku

Pokud server chce používat protokol TLS, musí jako ověřovací službu zadat Schannel (RPC_C_AUTHN_GSS_SCHANNEL) v asAuthSvc parametr CoInitializeSecurity. Aby se klienti nemohli připojit k serveru pomocí méně zabezpečené ověřovací služby, měl by server při volání CoInitializeSecurityzadat pouze Schannel jako ověřovací službu. Server nemůže změnit bezpečnostní deku po zavolání CoInitializeSecurity.

Pokud chcete použít protokol TLS, měly by být zadány následující parametry, pokud server volá CoInitializeSecurity:

• pVoid by měl být ukazatel na objekt IAccessControl nebo ukazatel na SECURITY_DESCRIPTOR. Neměl by být null ani ukazatel na APPID.
• cAuthSvc nemůže být 0 nebo -1. Když cAuthSvcje -1, servery COM nikdy nevybere Schannel.
• asAuthSvc musí jako možnou ověřovací službu zadat Schannel. To se provádí nastavením následujících parametrů SOLE_AUTHENTICATION_SERVICE pro člena Schannel SOLE_AUTHENTICATION_LIST:
  • dwAuthnSvc musí být RPC_C_AUTHN_GSS_SCHANNEL.
  • dwAuthzSvc by měla být RPC_C_AUTHZ_NONE. V současné době se ignoruje.
  • pPrincipalName musí být ukazatel na CERT_CONTEXT, přetypovat jako ukazatel na OLECHAR, který představuje certifikát X.509 serveru.
• dwAuthnLevel označuje minimální úroveň ověřování, která bude přijata z klientů pro úspěšné připojení. Nemůže být RPC_C_AUTHN_LEVEL_NONE.
• dwCapabilities by neměl mít nastavený příznak EOAC_APPID. Příznak EOAC_ACCESS_CONTROL by měl být nastaven, pokud pVoid odkazuje na objekt IAccessControl; nemělo by být nastaveno, pokud pVoid odkazuje na SECURITY_DESCRIPTOR. Další příznaky, které mohou být nastaveny, najdete v tématu CoInitializeSecurity.

Další informace o použití CoInitializeSecuritynaleznete v tématu Nastavení zabezpečení pro celou organizaci sCoInitializeSecurity .

Jak klient nastaví bezpečnostní deku

Pokud chce klient používat protokol TLS, musí v seznamu ověřovacích služeb v seznamu ověřovacích služeb v pAuthList parametru CoInitializeSecurity zadat Schannel (RPC_C_AUTHN_GSS_SCHANNEL). Pokud se při volání CoInitializeSecurity neurčí Schannel jako možná ověřovací služba, selže pozdější volání CoSetProxyBlanket (nebo IClientSecurity::SetBlanket).

Při volání klienta CoInitializeSecurityby se měly zadat následující parametry:

• dwAuthnLevel určuje výchozí úroveň ověřování, kterou chce klient použít. Nemůže být RPC_C_AUTHN_LEVEL_NONE.
• dwImpLevel musí být RPC_C_IMP_LEVEL_IMPERSONATE.
• pAuthList musí mít jako člena seznamu následující parametry SOLE_AUTHENTICATION_INFO:
  • dwAuthnSvc musí být RPC_C_AUTHN_GSS_SCHANNEL.
  • dwAuthzSvc musí být RPC_C_AUTHZ_NONE.
  • pAuthInfo je ukazatel na CERT_CONTEXT, přetypování jako ukazatel na void, který představuje certifikát X.509 klienta. Pokud klient nemá certifikát nebo nechce předložit svůj certifikát serveru, pAuthInfo musí být null a anonymní připojení se pokusí se serverem.
• dwCapabilities je sada příznaků, které označují další možnosti klienta. Informace o tom, které příznaky se mají nastavit, najdete v tématu CoInitializeSecurity.

Další informace o použití CoInitializeSecuritynaleznete v tématu Nastavení zabezpečení pro celou organizaci sCoInitializeSecurity .

Jak klient změní bezpečnostní deku

Pokud klient chce používat protokol TLS, ale po volání CoInitializeSecurityzměnit deku zabezpečení, musí volat CoSetProxyBlanket nebo IClientSecurity::SetBlanket s parametry podobnými parametrům, které se používají při volání CoInitializeSecurity, s následujícími rozdíly:

• pServerPrincName indikuje hlavní název serveru v msstd nebo fullsic formátu. Informace o těchtoformátch ch Pokud má klient certifikát X.509 serveru, může najít hlavní název voláním RpcCertGeneratePrincipalName.
• pAuthInfo je ukazatel na CERT_CONTEXT, přetypování jako ukazatel na RPC_AUTH_IDENTITY_HANDLE, který představuje certifikát X.509 klienta. Pokud klient nemá certifikát nebo nechce předložit svůj certifikát serveru, pAuthInfo musí být null a anonymní připojení se pokusí se serverem.
• dwCapabilities se skládá z příznaků, které označují další možnosti klienta. Ke změně nastavení deka zabezpečení je možné použít pouze čtyři příznaky: EOAC_DEFAULT, EOAC_MUTUAL_AUTH, EOAC_ANY_AUTHORITY (tento příznak je zastaralý) a EOAC_MAKE_FULLSIC. Další informace naleznete v tématu CoSetProxyBlanket.

Další informace o použití CoSetProxyBlanketnaleznete v tématu Nastavení zabezpečení na úrovni proxy rozhraní.

Příklad: Klient změní bezpečnostní deku

Následující příklad ukazuje, jak může klient změnit deku zabezpečení tak, aby vyhovoval požadavku ze serveru, aby klientovi poskytl certifikát X.509. Kód zpracování chyb je vynechán kvůli stručnosti.

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();
}

Související témata

balíčky COM a balíčky zabezpečení