Presentation by Jason Cohen, @asmartbear, WPEngine.com co-founder.
Theme: Security – requires trust
Privacy: trust in a shared secret.
- Enigma machines used in WWII by the Germans to send coded messages. One machine sent out a machine, and another with the same configuration could decode it.
- Algorithms are ways to encode things, and keys are the configuration. The algorithm can be open source and public. The key is what is secret.
- Example: Tiny Encryption Algorithm (TEA) – very simple chunk of code. Pretty secure.
Problem: How to make things tamper-proof?
- How would we know if a message has been messed with along the way. License codes work this way. An algorithm generates the code. But how do we prevent guessing or tampering.
Answer: Content + HMAC
Run code through an MD5 hash and that creates a signature.
- hash(content)
- hash(key + content)
- hash(key_saltA+ ontent)
- hash (key_saltA)+ hash (key_saltA+ content)
Problem: how to share a secret?
How do you share a secret with secure connections with banks, etc.? Back in the enigma days they actually met in person to share a key on a piece of paper
That isn’t feasible
Diffie Hellman
- Alice puts a secret in a box, puts a padlock on it. Lock A
- She sends this locked box to Bob. But it has a padlock.
- Bob puts his own padlock to Alice. Now it has locks A + B
- Alice removes her lock. Now it has lock B.
- Bob can now unlock the box.
How do we know that a spy isn’t involved and put his own lock on it? How does Alice know who is receiving the box?
Problem: Who the f*5k are you
- Quantum mechanics and black holes
- There’s no such thing as a vacuum – spontaneously two particles are created
- Quantum entanglement – particles p and q
- Symmetric key – same key s is used to encode and decode
- Asymmetric key – something encrypted with p can only be decoded with q and vice versa
- What if Bob creates a key, q, that he never shares with anyone, and publishes p everywhere. Public.
- Now Bob can tell Alice, he encrypted message with q, so she can decrypt it with p; if Alice or anyone else encrypts with p, only Bob can decode it.
Next issue of trust: if I am sure p is really Bob’s it’s cool. But how do we know?
Answer: Trusted directory of public keys.
- Directory entry: information about the entity with Public Key. We can trust the directory entry if VeriSign or another trusted directory has encrypted and alidated it.
- E.g. VeriSign – has its own public and private key
- A certificate is when one of these directory companies encrypts your information and verifies the entry.
- Problem: 100s of CAs – which Certificate Authority do I trust? Some are chains of CAs.
- If you look at your browser or laptop settings you will see certificates that are set by the companies behind each (e.g. Apple, Chrome etc).
TLS Handshake:
(aka HTTPS / SSL)
Chase bank: Hi I’m Chase Bank, heres my certificate signed by VeriSign
You: I trust VeriSign so I trust that P is Chase’s public key [p]. Here’s a secret key S. [s]
Chase: [p] okay I understand S. [p] let’s switch algorithms to [s] (Asymmetric keys are super slow, so let’s agree on a key and use a symmetric key algorithm.)
You: [p]okay
[s] blah blah (secure)
TLS: Fancy Pants!
- TCP “FIN” attack – checks for connection to be closed properly
- MD5 attack – hasn’t even happened yet but it’s already addressed – alternative hash to employ make sure an attack is useless
- Renegotiation – new shared keys and algorithms swapped out on the fly so that someone can’t crack it
HTTPS: Special considerations
- Slow to connect – can take seconds. Makes sites muuuch slower if everything is secure. You should only secure sensitive data.
- Keep-alive high – connection remains open and multiple bits of data can be shared. Can be shut down after a certain period of time e.g. 2 minutes
- Connection management – should not use Apache for secure stuff – will keep waiting for the keep alive, but takes up a lot of RAM. EngineX, Lightly, etc. that does better with connection management keeping internet connections alive. Only use Apache when running PHP.
- No virtual hosts (except SNI) – for SSL you can’t run multiple domains at one IP address. SSL secure connection happens first. Certificate has domain in it. Can only provide one certificate at a time. So you can’t have a second domain in the same connection. SNI web servers and browsers can do this. So you either need SNI or a separate IP for each domain.
- Can’t mix (faster) HTTP resources with HTTPS resources – cookies can be transferred and make connection insecure. So once HTTPS is connected it should all be HTTPS and not go back to HTTP.
SPDY: The future of the web?
- New protocol, not security protocol
- Speed: multiplexing, prioritization, compression
- Multiplexing: Browser asks for all resources at once instead of one at a time. Can go in batches. Can load a page twice as fast.
- Priortization: loads things in a different order to improve user experience
- Compression: compresses headers etc.
- Allows for a persistent connection: server push, server hint. Browser and server establish connection because server can push stuff instead of waiting on browser
- Security: SSL penalties significantly lessened – SPDY solves most of the reasons security is slow
- Google argues that using SPDY would make the whole web secure
- Very few browsers (Chrome) and servers don’t use SPDY for now – experimental
- W3C is forming a consortium
- More info: http://en.wikipedia.org/wiki/SPDY
Questions:
Self-sign certificate
- Here’s my public key. I don’t use VeriSign or anything else. No trust at all.
- Easy to set up, if you trust it, then it’s okay.
- Your WordPress login is completely insecure. If someone is watching packets at a coffee house then they can get your password.
- One way to solve that is to install a certificate. Expensive and somewhat difficult but you can encrypt the admin.
- Since you know it’s you logging in, you can use a self-signed certificate on your own server. Browser will ask and you’d be okay. NOT good for ecommerce. So it’s a good thing for your own login.
Shared Certificate
- Wildcard certificate e.g. *.wordpress.com so anything at WordPress.com can ride along
- GoDaddy is a certificate authority. They could issue you a certificate on the spot for a domain name.
- Just because you share a certificate, you aren’t sharing a TLS connection. Everything after a public key is unique so many users can be using a shared connection simultaneously.
Should you spring for your own IP address?
- It’s a trivial cost. Pay a buck or so a month for the IP address. You would need one for each domain that needs security.
When you go between secure and insecure connections does that hurt your connection? (e.g. going away from shopping car to read reviews, coming back to shopping cart).
- If the swapping is fast, probably not. If there’s more of a lag, but if it’s a problem, make the keep-alive window high. Some people will allow an entire site is HTTPS so once you leave the secure content, the site will keep as a secure connection.
For log in screen, use relative links rather than absolute links for images etc.
SPDY vs AJAX
- Completely different things. AJAX: browser is still pulling everything in one at a time. SPDY: things done in batches. Server can push things at you. Lazy loading, still AJAX.
With CDNs:
- When you have a secure page, the CDN can slow you down because it’s another connection. Because the latency is better between browser and CDN, it’s good if there’s a lot of secure requests. If there aren’t a lot of requests, it may not make sense. It depends.
SPDY would hopefully eliminate need for sprites