The process of verifying content by matching hashes ensures that only valid content is added to the cache, and the integrity of the local cache is protected. After a client computer locates the desired content on the content host, which is either a hosted cache server or a distributed cache mode client computer, the client computer begins the process of retrieving the content.
First the client computer sends a request to the content host for the first block that it requires. The request contains the Segment ID and block range that identify the desired content.
Because only one block is returned, the block range contains only a single block. Requests for multiple blocks are currently not supported.
The client also stores the request in its local Outstanding Request List. Upon receiving a valid request message from a client, the content host checks whether the block specified in the request exists in the content host's content cache. If the content host is in possession of the content block, then the content host sends a response that contains the Segment ID, the Block ID, the encrypted data block, and the initialization vector that is used for encrypting the block.
If the content host is not in possession of the content block, the content host sends an empty response message. This informs the client computer that the content host does not have the requested block. An empty response message contains the Segment ID and Block ID of the requested block, along with a zero-sized data block.
When the client computer receives the response from the content host, the client verifies that the message corresponds to a request message in its Outstanding Request List. The Segment ID and block index must match that of an outstanding request. If this verification process is unsuccessful and the client computer does not have a corresponding request message in its Outstanding Request List, the client computer discards the message.
If this verification process is successful and the client computer has a corresponding request message in its Outstanding Request List, the client computer decrypts the block.
The client then validates the decrypted block against the appropriate block hash from the content information that the client initially obtained from the original content server. If the complete segments of content do not exist on one computer, the retrieval protocol retrieves and assembles content from a combination of sources: a set of distributed cache mode client computers, a hosted cache server, and - if the branch office caches do not contain the complete content - the original content server in the main office.
Before BranchCache sends content information or content, the data is encrypted. BranchCache encrypts the block in the response message. In Windows 7, the default encryption algorithm that BranchCache uses is AES, the encryption key is Ke, and the key size is bits, as dictated by the encryption algorithm. BranchCache generates an initialization vector that is suitable for the encryption algorithm and uses the encryption key to encrypt the block.
BranchCache then records the encryption algorithm and the initialization vector in the message. Servers and clients never exchange, share, or send each other the encryption key. The client receives the encryption key from the content server that hosts the source content. Then, using the encryption algorithm and initialization vector it received from the server, it decrypts the block.
There is no other explicit authentication or authorization built into the download protocol. A client serving data to a requester tampers with the data. The BranchCache security model uses hashes to confirm that neither the client nor the server has altered the data. BranchCache sends encrypted content to any client that specifies the appropriate Segment ID. Segment IDs are public, so any client can receive encrypted content.
However, if a malicious user obtains encrypted content, they must know the encryption key to decrypt the content. The upper layer protocol performs authentication and then gives the content information to the authenticated and authorized client.
The security of the content information is equivalent to the security provided to the content itself, and BranchCache never exposes the content information. An attacker sniffs the wire to obtain the content. BranchCache encrypts all transfers between clients by using AES where the secret key is Ke, preventing data from being sniffed from the wire.
Content information that is downloaded from the content server is protected in exactly the same way as the data itself would have been and is hence no more or less protected from information disclosure than if BranchCache had not been used at all. A client is overwhelmed by requests for data. BranchCache protocols incorporate queue management counters and timers to prevent clients from being overloaded. On distributed cache mode client computers and hosted cache servers that are located in branch offices, content caches are built up over time as content is retrieved over WAN links.
When client computers are configured with hosted cache mode, they add content to their own local cache and also offer data to the hosted cache server. The Hosted Cache Protocol provides a mechanism for clients to inform the hosted cache server about content and segment availability.
To upload content to the hosted cache server, the client informs the server that it has a segment that is available. The hosted cache server then retrieves all of the content information that is associated with the offered segment, and downloads the blocks within the segment that it actually needs. This process is repeated until the client has no more segments to offer the hosted cache server.
To update the hosted cache server by using the Hosted Cache Protocol, the following requirements must be met:. The client computer is required to have a set of blocks within a segment that it can offer to the hosted cache server.
The client must supply content information for the offered segment; this is comprised of the Segment ID, the segment Hash of Data, the Segment Secret, and a list of all block hashes that are contained within the segment. For hosted cache servers that are running Windows Server R2, a hosted cache server certificate and associated private key are required, and the certification authority CA that issued the certificate must be trusted by client computers in the branch office.
Hosted cache servers that are running Windows Server , Windows Server R2 , or Windows Server do not require a hosted cache server certificate and associated private key. The client computer is configured with the computer name of the hosted cache server and the Transmission Control Protocol TCP port number upon which the hosted cache server is listening for BranchCache traffic.
The hosted cache server's certificate is bound to this port. The computer name of the hosted cache server can be a fully qualified domain name FQDN , if the hosted cache server is a domain member computer; or it can be the NetBIOS name of the computer if the hosted cache server is not a domain member. The client computer actively listens for incoming block requests.
The port on which it is listening is passed as part of the offer messages from the client to the hosted cache server. This enables the hosted cache server to use BranchCache protocols to connect to the client computer to retrieve data blocks in the segment.
If the hosted cache server is configured to require client computer authentication, both the client and the hosted cache server are required to support HTTPS authentication. The hosted cache server responds with an OK message and initiates the download of the missing blocks from the offering client computer.
The segment Hash of Data, list of block hashes, and the segment secret are used to ensure that the content that is being downloaded has not been tampered with or otherwise altered. The downloaded blocks are then added to the hosted cache server's block cache. This section provides information on how BranchCache secures cached data on client computers and on hosted cache servers. The greatest threat to data stored in the BranchCache is tampering.
If an attacker can tamper with content and content information that is stored in the cache, then it might be possible to use this to try and launch an attack against the computers that are using BranchCache. Attackers can initiate an attack by inserting malicious software in place of other data. BranchCache mitigates this threat by validating all content using block hashes found in the content information. If an attacker attempts to tamper with this data, it is discarded and is replaced with valid data from the original source.
A secondary threat to data stored in the BranchCache is information disclosure. In distributed cache mode, the client caches only the content that it has requested itself; however, that data is stored in clear text, and might be at risk. To help restrict cache access to the BranchCache Service only, the local cache is protected by file system permissions that are specified in an ACL. Although the ACL is effective in preventing unauthorized users from accessing the cache, it is possible for a user with administrative privileges to gain access to the cache by manually changing the permissions that are specified in the ACL.
BranchCache does not protect against the malicious use of an administrative account. Data that is stored in the content cache is not encrypted, so if data leakage is a concern, you can use encryption technologies such as BitLocker or the Encrypting File System EFS.
The local cache that is used by BranchCache does not increase the information disclosure threat borne by a computer in the branch office; the cache contains only copies of files that reside unencrypted elsewhere on the disk.
Encrypting the entire disk is particularly important in environments in which the physical security of the clients is difficult to ensure. For example, encrypting the entire disk helps to secure sensitive data on mobile computers that might be removed from the branch office environment. When installation is complete, click Close. Skip to main content. This browser is no longer supported. Download Microsoft Edge More info. Contents Exit focus mode. Is this page helpful?
Please rate your experience Yes No. For more information about how to obtain a Windows 7 or Windows Server R2 service pack, click the following article number to view the article in the Microsoft Knowledge Base:. The global version of this hotfix installs files that have the attributes that are listed in the following tables.
The dates and the times for these files on your local computer are displayed in your local time together with your current daylight saving time DST bias. Additionally, the dates and the times may change when you perform certain operations on the files.
Important Windows 7 hotfixes and Windows Server R2 hotfixes are included in the same packages. However, hotfixes on the Hotfix Request page are listed under both operating systems. Always refer to the "Applies To" section in articles to determine the actual operating system that each hotfix applies to.
The security catalog files, for which the attributes are not listed, are signed with a Microsoft digital signature. Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the "Applies to" section. For more information about software update terminology, click the following article number to view the article in the Microsoft Knowledge Base:.
General information about BranchCache. BranchCache guide for early adopters. Need more help? Expand your skills. Get new features first. Was this information helpful?
0コメント