- Сервер сети Microsoft: использовать цифровую подпись (всегда) Microsoft network server: Digitally sign communications (always)
- Справочные материалы Reference
- Возможные значения Possible values
- Рекомендации Best practices
- Расположение Location
- Значения по умолчанию Default values
- Управление политикой Policy management
- Необходимость перезапуска Restart requirement
- Вопросы безопасности Security considerations
- Уязвимость Vulnerability
- Противодействие Countermeasure
- Возможное влияние Potential impact
- Networking basics
- Capabilities
- Communicating when your app is not in the foreground
- Choosing a network trigger
- Secured connections
- Creating secure socket connections
- Use ConnectAsync
- Use UpgradeToSslAsync
- Creating secure WebSocket connections
- Authentication
- Providing a client certificate with the StreamSocket class
- Providing authentication credentials to a web service
- Handling network exceptions
Сервер сети Microsoft: использовать цифровую подпись (всегда) Microsoft network server: Digitally sign communications (always)
Область применения Applies to
- Windows 10. Windows 10
- Windows Server Windows Server
В этой статье описываются лучшие методики, расположение, значения, вопросы управления политиками и безопасности для сетевого сервера Майкрософт: параметр политики безопасности «Цифровая подпись» (всегда) для SMBv3 и SMBv2. Describes the best practices, location, values, policy management and security considerations for the Microsoft network server: Digitally sign communications (always) security policy setting for SMBv3 and SMBv2.
Справочные материалы Reference
Протокол SMB обеспечивает основу для общего доступа к файлам и печати и многих других сетевых операций, таких как удаленное администрирование Windows. The Server Message Block (SMB) protocol provides the basis for file and print sharing and many other networking operations, such as remote Windows administration. Чтобы предотвратить атаки «человек в середине», которые изменяют пакеты SMB при их переходе, протокол SMB поддерживает цифровую подпись пакетов SMB. To prevent man-in-the-middle attacks that modify SMB packets in transit, the SMB protocol supports the digital signing of SMB packets.
Реализация цифровых подписей в сетях с высоким уровнем безопасности помогает предотвратить подступы клиентских компьютеров и серверов, которые называются перехватом сеансов. Implementation of digital signatures in high-security networks helps prevent the impersonation of client computers and servers, which is known as «session hijacking.» Однако неправильное использование этих параметров политики может привести к сбою доступа к данным. But misuse of these policy settings can cause data access failure.
Начиная с клиентов и серверов SMBv2 подпись может быть обязательной или не обязательной. Beginning with SMBv2 clients and servers, signing can be either required or not required. Если этот параметр политики включен, клиенты SMBv2 будут подписывать все пакеты цифровой подписью. If this policy setting is enabled, SMBv2 clients will digitally sign all packets. Другой параметр политики определяет, требуется ли подпись для связи между серверами SMBv3 и SMBv2: сетевой клиент Майкрософт: цифровая подпись (всегда). Another policy setting determines whether signing is required for SMBv3 and SMBv2 server communications: Microsoft network client: Digitally sign communications (always).
Существует согласование между клиентом SMB и сервером SMB, чтобы решить, будет ли эффективно использоваться подпись. There is a negotiation done between the SMB client and the SMB server to decide whether signing will effectively be used. В следующей таблице приводится эффективное поведение для SMBv3 и SMBv2. The following table has the effective behavior for SMBv3 and SMBv2.
Сервер — обязательно Server – Required | Сервер — не требуется Server – Not Required | |
---|---|---|
Клиент — обязательно Client – Required | Подписано Signed | Подписано Signed |
Клиент — не требуется Client – Not Required | Подписано 1 Signed 1 | Не подписано 2 Not Signed 2 |
1 По умолчанию для трафика SMB контроллера домена 1 Default for domain controller SMB traffic 2 По умолчанию для всего другого трафика SMB 2 Default for all other SMB traffic
В SMBv2 улучшена производительность подписи SMB. Performance of SMB signing is improved in SMBv2. Дополнительные сведения см. в сведениях о потенциальном влиянии. For more details, see Potential impact.
Возможные значения Possible values
- Enabled Enabled
- Отключено Disabled
Рекомендации Best practices
Включить сетевой сервер Майкрософт: цифровая подпись (всегда). Enable Microsoft network server: Digitally sign communications (always).
Расположение Location
Конфигурация компьютера\Параметры Windows\Параметры безопасности\Локальные политики\Параметры безопасности Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options
Значения по умолчанию Default values
В следующей таблице перечислены фактические и эффективные значения по умолчанию для этой политики. The following table lists the actual and effective default values for this policy. Значения по умолчанию также можно найти на странице свойств политики. Default values are also listed on the policy’s property page.
Тип сервера или объект групповой политики Server type or GPO | Значение по умолчанию Default value |
---|---|
Default Domain Policy Default Domain Policy | Отключено Disabled |
Политика контроллера домена по умолчанию Default Domain Controller Policy | Включено Enabled |
Параметры по умолчанию для автономного сервера Stand-Alone Server Default Settings | Отключено Disabled |
Эффективные параметры по умолчанию для DC DC Effective Default Settings | Включено Enabled |
Действующие параметры по умолчанию для рядового сервера Member Server Effective Default Settings | Отключено Disabled |
Действующие параметры по умолчанию для клиентского компьютера Client Computer Effective Default Settings | Отключено Disabled |
Управление политикой Policy management
В этом разделе описываются функции и средства, которые помогут вам управлять этой политикой. This section describes features and tools that are available to help you manage this policy.
Необходимость перезапуска Restart requirement
Нет. None. Изменения этой политики становятся эффективными без перезапуска устройства, если они сохраняются локально или распространяются посредством групповой политики. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy.
Вопросы безопасности Security considerations
В этом разделе описывается, каким образом злоумышленник может использовать компонент или его конфигурацию, как реализовать меры противодействия, а также рассматриваются возможные отрицательные последствия их реализации. This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
Уязвимость Vulnerability
При перехвате сеанса используются средства, позволяющие злоумышленникам, которые имеют доступ к той же сети, что и клиентские устройства или серверы, прервать, закончить или украсть сеанс. Session hijacking uses tools that allow attackers who have access to the same network as the client device or server to interrupt, end, or steal a session in progress. Злоумышленники могут перехватывать и изменять неподписаные пакеты SMB, а затем изменять трафик и переадпорировать его, чтобы сервер мог выполнять нежелательные действия. Attackers can potentially intercept and modify unsigned Server Message Block (SMB) packets and then modify the traffic and forward it so that the server might perform objectionable actions. Кроме того, злоумышленник может представлять себя в качестве сервера или клиентского устройства после проверки подлинности и получить несанкционированный доступ к данным. Alternatively, the attacker could pose as the server or client device after legitimate authentication and gain unauthorized access to data.
SMB — это протокол общего доступа к ресурсам, поддерживаемый многими операционными системами Windows. SMB is the resource-sharing protocol that is supported by many Windows operating systems. Он является основой многих современных функций, таких как direct, реплика хранилища и SMB Direct, а также многих устаревших протоколов и средств. It is the basis of many modern features like Storage Spaces Direct, Storage Replica, and SMB Direct, as well as many legacy protocols and tools. Если ни одна из сторон не проходит проверку подлинности, передача данных не происходит. If either side fails the authentication process, data transmission does not take place.
Противодействие Countermeasure
Включить сетевой сервер Майкрософт: цифровая подпись (всегда). Enable Microsoft network server: Digitally sign communications (always).
Альтернативным мерой противодействия, которое может защитить весь сетевой трафик, является реализация цифровых подписей с помощью IPsec. An alternative countermeasure that could protect all network traffic is to implement digital signatures with IPsec. Существуют аппаратные ускорители для шифрования IPsec и подписи, которые можно использовать, чтобы свести к минимуму влияние на производительность ЦП серверов. There are hardware-based accelerators for IPsec encryption and signing that could be used to minimize the performance impact on the servers’ CPUs. Такие ускорители недоступны для подписи SMB. No such accelerators are available for SMB signing.
Возможное влияние Potential impact
Скорость хранения влияет на производительность. Storage speeds impact performance. Чем быстрее диск в источнике и назначении, тем выше пропускная способность, что приводит к большему использованию подписи ЦП. A faster drive on the source and destination allows more throughput, which causes more CPU usage of signing. Если вы используете сеть Ethernet объемом 1 ГБ или более низкую скорость хранения с современным ЦП, производительность будет ограничена. If you are using a 1 Gb Ethernet network or slower storage speed with a modern CPU, there is limited degradation in performance. Если вы используете более быструю сеть (например, 10 ГБ), влияние подписи на производительность может быть больше. If you are using a faster network (such as 10 Gb), the performance impact of signing may be greater.
Networking basics
Things you must do for any network-enabled app.
Capabilities
In order to use networking, you must add appropriate capability elements to your app manifest. If no network capability is specified in your app’s manifest, your app will have no networking capability, and any attempt to connect to the network will fail.
The following are the most-used networking capabilities.
Capability | Description |
---|---|
internetClient | Provides outbound access to the Internet and networks in public places, like airports and coffee shop. Most apps that require Internet access should use this capability. |
internetClientServer | Gives the app inbound and outbound network access from the Internet and networks in public places like airports and coffee shops. |
privateNetworkClientServer | Gives the app inbound and outbound network access at the user’s trusted places, like home and work. |
There are other capabilities that might be necessary for your app, in certain circumstances.
Capability | Description |
---|---|
enterpriseAuthentication | Allows an app to connect to network resources that require domain credentials. For example, an app that retrieves data from SharePoint servers on a private Intranet. With this capability your credentials can be used to access network resources on a network that requires credentials. An app with this capability can impersonate you on the network. You don’t need this capability in order to allow your app to access the Internet via an authenticating proxy. For more details, see the documentation for the Enterprise capability scenario in Restricted capabilities. |
proximity | Required for near-field proximity communication with devices in close proximity to the computer. Near-field proximity may be used to send or connect with an application on a nearby device. This capability allows an app to access the network to connect to a device in close proximity, with user consent to send an invite or accept an invite. |
sharedUserCertificates | This capability allows an app to access software and hardware certificates, such as smart card certificates. When this capability is invoked at runtime, the user must take action, such as inserting a card or selecting a certificate. With this capability, your software and hardware certificates or a smart card are used for identification in the app. This capability may be used by your employer, bank, or government services for identification. |
Communicating when your app is not in the foreground
Support your app with background tasks contains general information about using background tasks to do work when your app is not in the foreground. More specifically, your code must take special steps to be notified when it is not the current foreground app and data arrives over the network for it. You used Control Channel Triggers for this purpose in WindowsВ 8, and they are still supported in WindowsВ 10. Full information about using Control Channel Triggers is available here. A new technology in WindowsВ 10 provides better functionality with lower overhead for some scenarios, such as push-enabled stream sockets: the socket broker and socket activity triggers.
If your app uses DatagramSocket, StreamSocket, or StreamSocketListener, then your app can transfer ownership of an open socket to a socket broker provided by the system, and then leave the foreground, or even terminate. When a connection is made on the transferred socket, or traffic arrives on that socket, then your app or its designated background task are activated. If your app is not running, it is started. The socket broker then notifies your app using a SocketActivityTrigger that new traffic has arrived. Your app reclaims the socket from the socket broker and process the traffic on the socket. This means that your app consumes far less system resources when it is not actively processing network traffic.
The socket broker is intended to replace Control Channel Triggers where it is applicable, because it provides the same functionality, but with fewer restrictions and a smaller memory footprint. Socket broker can be used by apps that are not lock screen apps, and it is used the same way on phones as on other devices. Apps need not be running when traffic arrives in order to be activated by the socket broker. And the socket broker supports listening on TCP sockets, which Control Channel Triggers do not support.
Choosing a network trigger
There are some scenarios where either kind of trigger would be suitable. When you are choosing which kind of trigger to use in your app, consider the following advice.
- If you are using IXMLHTTPRequest2, System.Net.Http.HttpClient or System.Net.Http.HttpClientHandler, you must use ControlChannelTrigger.
- If you are using push-enabled StreamSockets, you can use control channel triggers, but should prefer SocketActivityTrigger. The latter choice allows the system to free up memory and reduce power requirements when the connection is not being actively used.
- If you want to minimize the memory footprint of your app when it is not actively servicing network requests, prefer SocketActivityTrigger when possible.
- If you want your app to be able to receive data while the system is in Connected Standby mode, use SocketActivityTrigger.
For details and examples of how to use the socket broker, see Network communications in the background.
Secured connections
Secure Sockets Layer (SSL) and the more recent Transport Layer Security (TLS) are cryptographic protocols designed to provide authentication and encryption for network communication. These protocols are designed to prevent eavesdropping and tampering when sending and receiving network data. These protocols use a client-server model for the protocol exchanges. These protocols also use digital certificates and certificate authorities to verify that the server is who it claims to be.
Creating secure socket connections
A StreamSocket object can be configured to use SSL/TLS for communications between the client and the server. This support for SSL/TLS is limited to using the StreamSocket object as the client in the SSL/TLS negotiation. You cannot use SSL/TLS with the StreamSocket created by a StreamSocketListener when incoming communications are received, because SSL/TLS negotiation as a server is not implemented by the StreamSocket class.
There are two ways to secure a StreamSocket connection with SSL/TLS:
- ConnectAsync — Make the initial connection to a network service and negotiate immediately to use SSL/TLS for all communications.
- UpgradeToSslAsync — Connect initially to a network service without encryption. The app may send or receive data. Then, upgrade the connection to use SSL/TLS for all further communications.
The SocketProtectionLevel specifies the desired socket protection level the app wants to establish or upgrade the connection with. However, the eventual protection level of the established connection is determined in a negotiation process between both endpoints of the connection. The result can be a lower protection level than the one you specified, if the other endpoint requests a lower level.
After the async operation has completed successfully, you can retrieve the requested protection level used in the ConnectAsync or UpgradeToSslAsync call through the StreamSocketinformation.ProtectionLevel property. However, this does not reflect the actual protection level the connection is using.
Your code should not implicitly depend on using a particular protection level, or on the assumption that a given security level is used by default. The security landscape changes constantly, and protocols and default protection levels change over time in order to avoid the use of protocols with known weaknesses. Defaults can vary depending on individual machine configuration, or on which software is installed and which patches have been applied. If your app depends on the use of a particular security level, then you must explicitly specify that level and then check to be sure that it is actually in use on the established connection.
Use ConnectAsync
ConnectAsync can be used to establish the initial connection with a network service and then negotiate immediately to use SSL/TLS for all communications. There are two ConnectAsync methods that support passing a protectionLevel parameter:
If the protectionLevel parameter is set to Windows.Networking.Sockets.SocketProtectionLevel.Ssl when calling either of the above ConnectAsync methods, the StreamSocket must will be established to use SSL/TLS for encryption. This value requires encryption and never allows a NULL cipher to be used.
The normal sequence to use with one of these ConnectAsync methods is the same.
- Create a StreamSocket.
- If an advanced option on the socket is needed, use the StreamSocket.Control property to get the StreamSocketControl instance associated with a StreamSocket object. Set a property on the StreamSocketControl.
- Call one of the above ConnectAsync methods to start an operation to connect to a remote destination and immediately negotiate the use of SSL/TLS.
- The SSL strength actually negotiated using ConnectAsync can be determined by getting the StreamSocketinformation.ProtectionLevel property after the async operation has completed successfully.
The following example creates a StreamSocket and tries to establish a connection to the network service and negotiate immediately to use SSL/TLS. If the negotiation is successful, all network communication using the StreamSocket between the client the network server will be encrypted.
Use UpgradeToSslAsync
When your code uses UpgradeToSslAsync, it first establishes a connection to a network service without encryption. The app may send or receive some data, then upgrade the connection to use SSL/TLS for all further communications.
The UpgradeToSslAsync method takes two parameters. The protectionLevel parameter indicates the protection level desired. The validationHostName parameter is the hostname of the remote network destination that is used for validation when upgrading to SSL. Normally the validationHostName would be the same hostname that the app used to initially establish the connection. If the protectionLevel parameter is set to Windows.System.Socket.SocketProtectionLevel.Ssl when calling UpgradeToSslAsync, the StreamSocket must use the SSL/TLS for encryption on further communications over the socket. This value requires encryption and never allows a NULL cipher to be used.
The normal sequence to use with the UpgradeToSslAsync method is as follows:
- Create a StreamSocket.
- If an advanced option on the socket is needed, use the StreamSocket.Control property to get the StreamSocketControl instance associated with a StreamSocket object. Set a property on the StreamSocketControl.
- If any data needs to be sent and received unencrypted, send it now.
- Call the UpgradeToSslAsync method to start an operation to upgrade the connection to use SSL/TLS.
- The SSL strength actually negotiated using UpgradeToSslAsync can be determined by getting the StreamSocketinformation.ProtectionLevel property after the async operation completes successfully.
The following example creates a StreamSocket, tries to establish a connection to the network service, sends some initial data, and then negotiates to use SSL/TLS. If the negotiation is successful, all network communication using the StreamSocket between the client and the network server will be encrypted.
Creating secure WebSocket connections
Like traditional socket connections, WebSocket connections can also be encrypted with Transport Layer Security (TLS)/Secure Sockets Layer (SSL) when using the StreamWebSocket and MessageWebSocket features for a UWP app. In most cases you’ll want to use a secure WebSocket connection. This will increase the chances that your connection will succeed, as many proxies will reject unencrypted WebSocket connections.
For examples of how to create, or upgrade to, a secure socket connection to a network service, see How to secure WebSocket connections with TLS/SSL.
In addition to TLS/SSL encryption, a server may require a Sec-WebSocket-Protocol header value to complete the initial handshake. This value, represented by the StreamWebSocketInformation.Protocol and MessageWebSocketInformation.Protocol properties, indicate the protocol version of the connection and enables the server to correctly interpret the opening handshake and the data being exchanged afterwards. Using this protocol information, if at any point if the server cannot interpret the incoming data in a safe manner the connection can be closed.
If the initial request from the client either does not contain this value, or provides a value that doesn’t match what the server expects, the expected value is sent from the server to the client on WebSocket handshake error.
Authentication
How to provide authentication credentials when connecting over the network.
Providing a client certificate with the StreamSocket class
The Windows.Networking.Sockets.StreamSocket class supports using SSL/TLS to authenticate the server the app is talking to. In certain cases, the app also needs to authenticate itself to the server using a TLS client certificate. In WindowsВ 10, you can provide a client certificate on the StreamSocket.Control object (this must be set before the TLS handshake is started). If the server requests the client certificate, Windows will respond with the certificate provided.
Here is a code snippet showing how to implement this:
Providing authentication credentials to a web service
The networking APIs that enable apps to interact with secure web services each provide their own methods to either initialize a client or set a request header with server and proxy authentication credentials. Each method is set with a PasswordCredential object that indicates a user name, password, and the resource for which these credentials are used. The following table provides a mapping of these APIs:
WebSockets | MessageWebSocketControl.ServerCredential |
---|---|
MessageWebSocketControl.ProxyCredential | |
StreamWebSocketControl.ServerCredential | |
StreamWebSocketControl.ProxyCredential | |
Background Transfer | BackgroundDownloader.ServerCredential |
BackgroundDownloader.ProxyCredential | |
BackgroundUploader.ServerCredential | |
BackgroundUploader.ProxyCredential | |
Syndication | SyndicationClient(PasswordCredential) |
SyndicationClient.ServerCredential | |
SyndicationClient.ProxyCredential | |
AtomPub | AtomPubClient(PasswordCredential) |
AtomPubClient.ServerCredential | |
AtomPubClient.ProxyCredential |
Handling network exceptions
In most areas of programming, an exception indicates a significant problem or failure, caused by some flaw in the program. In network programming, there is an additional source for exceptions: the network itself, and the nature of network communications. Network communications are inherently unreliable and prone to unexpected failure. For each of the ways your app uses networking, you must maintain some state information; and your app code must handle network exceptions by updating that state information and initiating appropriate logic for your app to re-establish or retry communication failures.
When Universal Windows apps throw an exception, your exception handler can retrieve more detailed information on the cause of the exception to better understand the failure and make appropriate decisions.
Each language projection supports a method to access this more detailed information. An exception projects as an HRESULT value in Universal Windows apps. The Winerror.h include file contains a very large list of possible HRESULT values that includes network errors.
The networking APIs support different methods for retrieving this detailed information on the cause of an exception.
- Some APIs provide a helper method that converts the HRESULT value from the exception to an enumeration value.
- Other APIs provide a method to retrieve the actual HRESULT value.