Web Security Shorts Browser Encryption Or How I

Web Security Shorts Browser Encryption Or: How I learned to stop worrying and love the padlock

A common scenario GET https: //www. washington. edu HTTP/1. 1 200 OK. . .

A common scenario https ● But what about it, exactly, is awesome? ● How did it become awesome? ● And, are there limits to this awesomeness?

Encryption Specifically, SSL/TLS encryption GET https: //www. washington. edu HTTP/1. 1 200 OK. . .

Why Encryption Is Awesome All traffic between my browser and a specific server cannot be understood by anyone who may intercept it. So, passwords, financial information, etc. , shared between the browser and this server are “safe” from prying eyes. But how does it happen?

SSL/TLS Encryption - How? 1. After initially being contacted by browser, the server sends its certificate. Wait. Certificate ?

The Certificate Just a file! Issued by a certificate authority, and contains: ● Identity information for organization, domain ● Issuer’s information ● Period of validity ● Server’s public key (one half of the public/private key pair) Wait. Key pair?

The Key Pair Public Key Private Key ● Derived together as a pair, and issued by a certificate authority with a certificate ● One key cannot be derived from the other (thanks math!)

The Key Pair Public ● Not secret, can be distributed to anyone ● Used to encrypt information sent to owner of matching private key Private ● Must be kept secret ● Used to decrypt info encrypted with matching public key ● Also used to “sign” (encrypt) info to be verified with public key

SSL/TLS Encryption - How? 1. After initially being contacted by browser, the server sends its certificate.

SSL/TLS Encryption - How? 2. Browser verifies server certificate by following issuers and their respective certs all the way to the root certificate, which is loaded on the browser. ROOT

SSL/TLS Encryption - How? 3. Browser computes a random byte string, encrypts it with the server’s public key (from the server’s certificate), and sends to server. 67 ERG 89335 GDNHHA 9945 H 34 UIT 6456 AE 56 G 443 TERF 230 YTHG 12 VBN 250 TEFE 4453 RDVBN I

SSL/TLS Encryption - How? 3. Browser computes a random byte string, encrypts it with the server’s public key (from the server’s certificate), and sends to server. 67 ERG 89335 GDNHHA 9945 H 34 UIT 6456 I

SSL/TLS Encryption - How? 4. Server decrypts the string with its private key. 67 ERG 89335 GDNHHA 9945 H 34 UIT 6456 AE 56 G 443 TERF 230 YTHG 12 VBN 250 TEFE 4453 RDVBN I

SSL/TLS Encryption - How? 4. Browser and server now use that secret string to derive (yes, more math!) a new key they’ll both use to communicate from that point forth. AE 56 G 443 TERF 230 YTHG 12 VBN 250 TEFE 4453 RDVBN OK, everything IS awesome, but are there limits?

Trust! Entire system relies on trusting the organizations that issue certificates, the certificate authorities (CAs). In theory, CAs vet people/organizations requesting certs before granting them. In practice, it’s a little more complicated, since there are multiple types of certificates, each with a different level of vetting.

Certificate types Domain Validated (DV) ● Minimal validation: only that the applicant owns the domain ● Browsers typically indicate DV certs with a single padlock ● Certificate will not have “Issued To Organization” information ● Relatively cheap, easy, and fast to obtain

Certificate types Organization Validated (OV) ● More validation than DV certs, including the verification of the business attempting to acquire the certificate ● As with DV certs, browsers typically indicate OV certs with a single padlock ● Certificate will have “Issued To Organization” information

Certificate types Extended Validation (EV) ● Max (most strict) validation possible, requiring additional applicant paperwork (and $) ● Shown in browsers with padlock and name of company or organization in green This (name/org in green) is the key difference between EV and OV certs

Free SSL Certificates! Let’s Encrypt A nonprofit global certificate authority, offering DV certs only. Somewhat easier to implement than standard HTTPS. Clouldflare SSL Service Essentially a proxy (with cert) your server uses. Easy to set up, varied levels of configuration.

So, what could possibly go wrong?

An unscrupulous scenario 1. Purchase the domain “banskfamerica. com”

An unscrupulous scenario 2. Purchase a Domain Validated (DV) certificate for “banskfamerica. com” from a certificate authority (CA) banskfamerica. com (Remember, since it’s a DV cert, the only validation the issuing CA will perform is to verify that I own the domain. And I can be anybody. )

An unscrupulous scenario 3. Build a login page on the “banskfamerica. com” domain that looks strikingly similar to that of another well known site

An unscrupulous scenario 4. Wait patiently for an online banking customer who also happens to be a fat-fingered typist in a hurry 5. Or, email a link to this page urging recipient to login to avoid having account shut down

What can you do?

Recommendations ● Understand what the browser’s padlock actually indicates, along with its limitations ● Double-check URLs when visiting sensitive sites (financial login pages, etc. ) ● When accessing sensitive sites, do so at a more leisurely (less typo-prone) pace ● Never login from a page reached by clicking an email link (in fact, avoid clicking email links altogether unless you’re 100% sure they’re safe)

Resources & Further Reading ● ● A Beginner’s Guide to SSL Certificates (Symantec Security) https: //www. websecurity. symantec. com/content/dam/websitesecurity/digitalassets/desk top/pdfs/whitepaper/beginners-guide-to-SSL-certificates_WP. pdf A deep(er) technical dive into SSL/TLS encryption (IBM) https: //www. ibm. com/support/knowledgecenter/SSFKSJ_7. 1. 0/com. ibm. mq. doc/sy 10630 _. htm “Can we really trust the browser padlock? Fake banking sites given TLS certificates” (Sophos Naked Security Blog, Oct 2015) https: //nakedsecurity. sophos. com/2015/10/14/can-we-really-trust-the-browser-padlockfake-banking-sites-given-tls-certificates/ “Vast majority of newly registered domains are malicious” (SC Magazine, Aug 2019) https: //www. scmagazine. com/home/security-news/malware/vast-majority-of-newlyregistered-domains-are-malicious/

Questions? Peter Giles gilesp@uw. edu Pete Graff pgraff@uw. edu

Secure Coding Class ● Learn to think like an attacker, and get hands-on experience hacking a vulnerable web application ● Explore common vulnerabilities such as XSS, SQL injection, and web parameter tampering ● 3 hours ● Contact Pete Graff (pgraff@uw. edu)