Dlaczego tak trudno jest włączyć SSL (bezpieczeństwo transportu) przez net.tcp niż HTTP?

Question

Wdrożenie usługi sieci web, który używa zabezpieczeń na poziomie transportu z WCF przez HTTP jest dość proste: Enable SSL for my WCF service

Wdrożenie usługi sieci web, który używa zabezpieczeń na poziomie transportu z WCF nad Net.TCP jest dość trudne: WCF with netTcpBinding and Certificate transport security

... i roztwór Net.TCP zwykle wiąże się coś takiego zarówno po stronie serwera i po stronie klienta:

<serviceCertificate 
     findValue="MyServiceCertificate" 
     storeLocation="LocalMachine" 
     storeName="My" 
     x509FindType="FindBySubjectName" /> 

w przypadku HTTP, nie trzeba nawet wspominać certyfikatu na każdym kliencie lub na serwerze. W przypadku NET.TCP należy przechowywać, lokalizować i określać certyfikat zarówno na kliencie, jak i na serwerze w większości źródeł, które przeczytałem.

Co sprawia, że ​​korzystanie z magii sprawia, że ​​nie musisz się martwić o certyfikaty w trybie HTTP? I dlaczego ta magia nie jest dostępna podczas korzystania z net.tcp?

Answer 1

Ponieważ podczas korzystania z WCF przez HTTPS; Usługi IIS zarządzają negocjacjami z certyfikatami (podobnie jak zwykły protokół SSL). Ponieważ nie ma serwera IIS z wbudowanym dla TCP, musisz zrobić to sam. Wciąż robisz rzeczy z certyfikatami + WCF dla HTTPS, ale konfiguracja jest wykonywana w IIS.

EDIT:

Na stronie klienta, trzeba jeszcze inny kawałek oprogramowania. Podczas przeglądania witryny za pośrednictwem protokołu SSL przeglądarka obsługuje to wszystko. Protokół SSL przez HTTP ma standardowy wzorzec negocjacji, ponieważ jest częścią protokołu HTTPS. W przypadku TCP nie jest to częścią protokołu, więc klient musi sam zająć się tym.

Answer 2

Walczyłem z tym jak cholera, a teraz w końcu czuję się jak idiota. Co jest miłe, ponieważ oznacza to, że właściwie rozumiem coś, o czym wcześniej się hakerowałem.

Podczas realizacji usługi Twoim celem jest zabezpieczenie komunikacji za pomocą protokołu SSL. Musisz również móc wygenerować plik reference.cs w visual studio. Problemem jest to, że umieszczasz swoją wymianę meta-danych również pod opcją SSL. Narzędzia do generowania kodu nie pozwalają na skonfigurowanie niezbędnych sekcji konfiguracji NetTcpBinding dla wywołań, które są tworzone w celu pobrania metadanych, gdy są używane do generowania pliku reference.cs.

Należy utworzyć dwa osobne konfiguracje wiążące zgodnie netTcpBinding, jeden dla usługi z:

<security mode="TransportWithMessageCredential"> 
    <message clientCredentialType="Certificate"/> 
</security> 

config wewnątrz i inny z:

<security mode="None" /> 

zamiast. Upewnij się, że wszystkie inne ustawienia są zgodne i punkt końcowy dla punktów usługowych na ssl bindingConfig, podczas gdy punkt końcowy metadanych wskazuje na brak powiązania SSL. Będziesz wtedy mógł odczytywać metadane i ponownie aktualizować odniesienie do usługi.

Jedną z rzeczy, na którą należy zwrócić uwagę, jest to, że powinieneś zająć się wiązaniem meta-danych dla każdego wydania prod. Gwarantuje to, że nie ujawniasz niczego, co nie jest przez SSL.