PGP is a product that encrypts your data to keep it safe from unauthorized access. The University is now supporting two components of PGP: Whole Disk Encryption and NetShare. Installation of the PGP Desktop application is required to use either component. For information about purchasing licenses, please see our PGP Information page.
NOTE: Do not install PGP Desktop on MacOS 10.7.3. There are unresolved issues with the software on this version of OSX.
|Installer||PGP Desktop for MacOSX Installer|
|How To||Install PGP Desktop for MacOSX (Video)*|
|Quick Start||PGP Desktop 10.2 for MacOSX Quick Start Guide*|
|User Guide||PGP Desktop 10.2 for MacOSX User's Guide*|
|Installer||PGP Desktop for Windows 32-bit Installer|
|PGP Desktop for Windows 64-bit Installer|
|How To||Installing the Client Software and User Enrollment|
|Installing the Client Software from AD Joined Systems|
|Install PGP Desktop for Windows (Video)*|
|Quick Start||PGP Desktop 10.2 for Windows Quick Start Guides*|
|User Guide||PGP Desktop 10.2 for Windows User's Guides*|
|Links to Many Other Installation/Upgrade/User's/Admin Guides*|
Using PGP Whole Disk Encryption (WDE), your entire disk is encrypted. After encryption, you will enter a passphrase when you start you computer. Not all computers need to be encrypted. If you have questions about your computer and the data stored on it, contact your departmental support technician, or contact the OIT Service Desk at 3-1222.
|How To||Setting Up Whole Disk Encryption (Windows)|
|User Guide||PGP Whole Disk User Guides*|
|PGP Whole Disk Command Line User Guide*|
|Product Information||PGP Whole Disk Encryption at Symantec*|
|Current Issues||Unable to boot after installing MacOSX 10.7.3 on encrypted disk*|
|PGP Whole Disk Encryption for MacOSX Recovery Disk Images*|
PGP NetShare is a Windows only feature that allows you to create a secure file store either on your local computer or a network share. All files saved into this folder are automatically encrypted. If you have questions about setting up or using this feature, contact your departmental support technician or the OIT Service Desk at 3-1222.
|How To||Setting up a NetShare Folder|
|Adding or Removing Users/Groups from a NetShare Folder|
|User Guide||PGP NetShare Command Line User Guide*|
|Product Information||PGP NetShare at Symantec*|
|How To||Creating a Self Decrypting Passphrase Protected File|
*These links navigate to outside sources.
Never share your passwords with others, including your supervisor or coworkers. Your password is a secret; it only works if only you know it. If anyone else knows your password, you may be responsible for their actions.
Original release date: March 16, 2017
All systems behind a hypertext transfer protocol secure (HTTPS) interception product are potentially affected.
Many organizations use HTTPS interception products for several purposes, including detecting malware that uses HTTPS connections to malicious servers. The CERT Coordination Center (CERT/CC) explored the tradeoffs of using HTTPS interception in a blog post called The Risks of SSL Inspection .
Organizations that have performed a risk assessment and determined that HTTPS inspection is a requirement should ensure their HTTPS inspection products are performing correct transport layer security (TLS) certificate validation. Products that do not properly ensure secure TLS communications and do not convey error messages to the user may further weaken the end-to-end protections that HTTPS aims to provide.
TLS and its predecessor, Secure Sockets Layer (SSL), are important Internet protocols that encrypt communications over the Internet between the client and server. These protocols (and protocols that make use of TLS and SSL, such as HTTPS) use certificates to establish an identity chain showing that the connection is with a legitimate server verified by a trusted third-party certificate authority.
HTTPS inspection works by intercepting the HTTPS network traffic and performing a man-in-the-middle (MiTM) attack on the connection. In MiTM attacks, sensitive client data can be transmitted to a malicious party spoofing the intended server. In order to perform HTTPS inspection without presenting client warnings, administrators must install trusted certificates on client devices. Browsers and other client applications use this certificate to validate encrypted connections created by the HTTPS inspection product. In addition to the problem of not being able to verify a web servers certificate, the protocols and ciphers that an HTTPS inspection product negotiates with web servers may also be invisible to a client. The problem with this architecture is that the client systems have no way of independently validating the HTTPS connection. The client can only verify the connection between itself and the HTTPS interception product. Clients must rely on the HTTPS validation performed by the HTTPS interception product.
A recent report, The Security Impact of HTTPS Interception , highlighted several security concerns with HTTPS inspection products and outlined survey results of these issues. Many HTTPS inspection products do not properly verify the certificate chain of the server before re-encrypting and forwarding client data, allowing the possibility of a MiTM attack. Furthermore, certificate-chain verification errors are infrequently forwarded to the client, leading a client to believe that operations were performed as intended with the correct server. This report provided a method to allow servers to detect clients that are having their traffic manipulated by HTTPS inspection products. The website badssl.com  is a resource where clients can verify whether their HTTPS inspection products are properly verifying certificate chains. Clients can also use this site to verify whether their HTTPS inspection products are enabling connections to websites that a browser or other client would otherwise reject. For example, an HTTPS inspection product may allow deprecated protocol versions or weak ciphers to be used between itself and a web server. Because client systems may connect to the HTTPS inspection product using strong cryptography, the user will be unaware of any weakness on the other side of the HTTPS inspection.
Because the HTTPS inspection product manages the protocols, ciphers, and certificate chain, the product must perform the necessary HTTPS validations. Failure to perform proper validation or adequately convey the validation status increases the probability that the client will fall victim to MiTM attacks by malicious third parties.
Organizations using an HTTPS inspection product should verify that their product properly validates certificate chains and passes any warnings or errors to the client. A partial list of products that may be affected is available at The Risks of SSL Inspection . Organizations may use badssl.com  as a method of determining if their preferred HTTPS inspection product properly validates certificates and prevents connections to sites using weak cryptography. At a minimum, if any of the tests in the Certificate section of badssl.com prevent a client with direct Internet access from connecting, those same clients should also refuse the connection when connected to the Internet by way of an HTTPS inspection product.
In general, organizations considering the use of HTTPS inspection should carefully consider the pros and cons of such products before implementing . Organizations should also take other steps to secure end-to-end communications, as presented in US-CERT Alert TA15-120A .
Note: The U.S. Government does not endorse or support any particular product or vendor.