Download file and extract to get the NTLM Auth capture file. ... View more

Introduction The HTTPS Proxy is a powerful tool on the Web Security Appliance (WSA) that can be used for filtering HTTPS traffic. In order to utilize this feature, it must be configured correctly. In this article, I will review the steps required to configure the HTTPS Proxy.   Problem The WSA does not filter HTTPS traffic by default. In order to filter HTTPS traffic, you must enable the HTTPS Proxy. This article discusses the steps required to configure the HTTPS Proxy.   Solution 1) To enable the HTTPS Proxy, access the WSA GUI and go to Security Services > HTTPS Proxy.   2) Click on Enable and Edit Settings and click the box next to "Enable HTTPS Proxy".     3) The WSA must have a root or intermediate certificate in order for the HTTPS Proxy to work. There are a few options for getting that certificate on the box, which are listed below: Generate the Certificate and Key on the WSA      - Click on the "Generate New Certificate and Key" button      - Fill out the fields for the new Certificate and Key      - Click "Generate" when done Generate a Certificate and Key and download a CSR to have signed by a CA      - Follow the steps for "Generate the Certificate and Key on the WSA" above      - Click on the link for "Download Certificate Signing Request" and save the file in PEM format      - Take the file to your CA and have it signed      - Click "Browse" under the section "Signed Certificate" to upload the signed certificate   *Important* The CA cannot be a third party trusted CA, such as Verisign or Thawte, as they will not sign an intermediate or root certificate. Upload an existing Certificate and Key      - Click on the box next to "Use Uploaded Certificate and Key"      - Select "Browse" to search for the Certificate and Key (as stated, Private key must be unencrypted)      - Click "Upload Files" to upload the certificate and key     4) (Optional) Configure the other settings for the HTTPS Proxy   Version 7.5 and earlier HTTPS Transparent Request      - This is to determine how to handle HTTPS traffic in regards to unauthenticated users that require authentication. This is almost always set to the default setting of "Decrypt the HTTPS request and redirect for authentication". Applications that Use HTTPS      - This settings is enabled by default and allows the WSA to decrypt HTTPS requests that may be subject to the Application Visibility and Control feature. This setting only takes affect if the web category decision is "Monitor" in the decryption policies. Invalid Certificate Handling      - These settings determine how the WSA will handle HTTPS sites that present a certificate that is not valid for the reasons listed in this section. These settings are applied prior to the web category decision in the Decryption policies except for Custom Categories that are set to Passthrough.   Version 7.7 and later Decryption Options      - These options include decryption for Authentication, End User Notification, End User Acknowledgement, and Application Detection. In order to use these features for HTTPS requests, the WSA must decrypt these transactions. Online Certificate Status Protocol Options      - These settings deal with how the WSA handles Online Certificate Status Protocol (OCSP) checks. The WSA only uses the OCSP feature if the certificate is valid. Certificate Management      - This section allows configuration and management of the trusted Certificate Authorities on the WSA. The "Manage Trusted Root Certificates" allows for importing custom Root Certificate Authorities to be trusted by the WSA as well as overriding existing Certificate Authorities from being trusted.   5) Submit and Commit the changes!!!   The HTTPS Proxy has now been configured. Below are some items to consider, now that the HTTPS Proxy has been enabled, that are not covered in this guide: Configuring the Decryption policies Re-directing the HTTPS traffic via WCCP Uploading the Certificate used for the HTTPS Proxy to users' browsers ... View more

Introduction At any point in time on a network, there are multiple threats and vulnerabilities present, especially when it comes to Internet traffic. To help mitigate these threats and vulnerabilities, the Cisco Web Security Appliance (WSA) can be used as a filter for HTTP. It is important to know how the Web Proxy feature works in order to understand how the WSA will affect HTTP traffic and help protect users from malicious content.   Problem The WSA is a web proxy that can filter HTTP, HTTPS, and FTP traffic. The most common protocol that is filtered is HTTP, which is handled by the Web Proxy. In this guide, I will discuss how the Web Proxy feature works on the WSA.   Solution A proxy, in technical terms, is an entity that acts on behalf of another entity. A Web Proxy, as in the case of the WSA, acts as a middle man between a client and server. In order for the WSA to proxy Internet traffic, it must first receive the traffic from the clients. There are numerous methods for sending user traffic to the WSA, both explicit and transparent, which are covered in the Proxy Deployment guide. Once the WSA receives the user traffic, it establishes two sockets. One socket is between the client and the WSA. The other socket is between the WSA and the destination server, also known as the Origin Content Server (OCS). Each socket will be established via a TCP handshake as illustrated below.   Client to WSA 1)    Client sends SYN to WSA (if explicit) or OCS (if transparent) 2)    WSA responds with SYN, ACK to client with a source IP address of the WSA data interface (if explicit) or OCS (if transparent) 3)    Client responds with ACK and TCP handshake is complete   Wireshark Capture of Client to WSA socket      WSA to OCS 1)    WSA sends SYN to OCS with a source IP address of the WSA data interface (unless IP spoofing is enabled) 2)    OCS responds with SYN, ACK to WSA 3)    WSA responds with ACK and TCP handshake is complete   Wireshark Capture of WSA to OCS socket     Once a TCP handshake is complete between the WSA and the client, the client will send a HTTP request to the WSA. At this point, the WSA evaluates its policies to determine if the client traffic is allowed. If the traffic is allowed, then the WSA creates its TCP handshake with the OCS and sends the same HTTP request that was sent by the client. Once the OCS sends its HTTP response, the WSA evaluates the content to determine if the traffic is still allowed based on its policies. If the content passes the response side checks, then the HTTP response and content are returned to the client.   Wireshark Capture of HTTP Request and Response (blue is Client to WSA socket and green is WSA to OCS socket)     Wireshark Capture of HTTP Request and Response when site is blocked by Access Policy       Scenario 2:   Problem: User would like to know how long does WSA takes to sync with Active directory? Any time frame? For an example WSA sync every 1 hr with Active Directory. Solution: It doesn't "sync" There a couple of ways to get AD auth. Transparent auth, where you join the WSA to the domain, and as users hit web pages and are redirected, they get auth. AD Agent or now the CDA, and soon ICE... Users login to AD, the ADAgent/CDA/ICE see the activity in the domain controller logs and pass that info to the WSA. ... View more

Greetings All! I wanted to make everybody aware of an issue that is occurring for iPhone and iPad upgrades from 7.0 - 7.0.2 through the WSA. For versions 7.5.x and 7.7.x of the WSA, the upgrade will fail almost immediately. The issue is that the WSA changes the Last Modified header from GMT to UTC, which breaks RFC and the iOS update (tracked under bug CSCzv03132). We have confirmed that going through a box where this behavior doesn’t occur the update succeeds. While a fix for the bug is being worked on, the only workaround at this time is to bypass either the client IP address or the following domains (bypassing on domain may or may not work as they use Akamai servers and could resolve to different IP addresses for the bypass settings): mesu.apple.com appldnld.apple.com To bypass the client IP address(es) or domains go to Web Security Manager > Bypass settings from the WSA GUI or you can deny redirection for the IP address/subnet by modifying the redirect-list being used for WCCP. Regards, Jeff Richmond Customer Support Engineer Content Security Technical Services (CSTS) - Web Security ... View more