-
Notifications
You must be signed in to change notification settings - Fork 30
/
Lecture07.tex
139 lines (106 loc) · 6.31 KB
/
Lecture07.tex
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
%!TEX root = InfoSec.tex
% Lecture 7: 1 October 2014
\sektion{7}{SSL/TLS and Public Key Infrastructure}
\textit{Note: See piazza for lecture slides}
Assumptions when logging in to, say Facebook on a Firefox browser
\begin{itemize}
\item Firefox is behaving correctly
\item HTTPS certification is working correctly
\item Facebook's url is indeed facebook.com
\end{itemize}
But you must first verify all the above properties when you download firefox\\
But you must first update IE...
Essentially, you need a chain of digital certificates that verify the signatures
on each subsequent certificate or the website in question.
So, who is the entity on top?
{\bf Verisign}\\
\begin{itemize}
\item a company in the business of verifying websites
\item firefox has decided to trust verisign certificates by default\\
But this means firefox must be working correctly, to both verify
certificates and trust Verasign!
\end{itemize}
Essentially, there is a \textit{massive} tree of entities we need to trust to do
anything on the internet.
\subsektion{Observations on trust}
Trust is not transitive.
The roots of trust are (hopefully a small number of) brands, such as
Microsoft, Dell, Mozilla, etc. Ideally, a user does not have to remember all
the trustworthy brand urls.
What's \textbf{not} here:\\
wireless routers, the government, ISP.
Even though we don't trust the network, a MITM attack is not possible because of
authenticated key exchange and TLS/SSL protocols. Crypto allows us to not trust the
network.
\subsektion{Another problem}
How does Firefox know that Facebook's cert was signed by Verasign? Because Facebook said so!
So what if Facebook provides a different cert authority?
Theory: We would only accept it if we trust the new CA\\
Pracice: Firefox comes with a list of trusted CAs. However, if any one of them is malicious, it can certify any other malicious urls and you are screwed.
\subsektion{Attacks}
If there exists an adversary (let's call it NSA, for non-specific adversary) and
a rogue CA, how might they MITM you?
\begin{enumerate}
\item Issue rogue certs for target sites
\item Select users ot target, install MITM boxes at their ISP(s)
\end{enumerate}
How are these attacks detected?
\begin{enumerate}
\item Browser remembers old cert and alerts server if ``something's wrong'' ie. the new one seems suspicious
\item Server notices lots of users logging in from the same IP (or better, the same
device fingerprint)
\end{enumerate}
Because it's easily detected, having a NSA MITM-ing seems pretty uncommon.
\subsektion{Public Key Infrastructure}
Infrastructure to create, distribute, validate, and revoke certs.
It is comprised of a small number of roots hierarchically certifying various entities.
Clients trust these roots, and transitively follow the chain of trust from server back
to a root. The standard is X.509 (which has a full spec of thousands of pages. Really).
There are generally cross-links between root CAs in that they certify each other, so that even if you remove root C as a trusted root CA, roots A and B might delegate to C,
meaning it is still trusted.
\subsektion{Certificates}
Binds an entity to a public key. Signed by some issuer (CA) and contains identity of issuer and an expiration time.
\textbf{How does a server obtain a cert?} The server generates a key pair and signs its public key and ID info with its private key to prove that server holds the private key; also provides message authentication.\\
The CA verifies the server's signature using the server's public key. Hard problem: How do you know that it's actually the server that's sending the info?\\
The CA then signs the server's public key with CA key which creates a binding. It the server can verify the key, ID, and CA's signature, it's good to go.
\textit{Almost all SSL clients except browsers and key SSL libraries are broken,
often in hilarious ways.}
\textbf{Three hard problems}
\begin{enumerate}
\item Naming and identity verification. How do you know that whoever is requesting
a certificate is who they say they are?
\item Anchoring. Who are the roots that are trustworthy?
\item Revocation. If something goes wrong, how can they shut off a certificate?
\end{enumerate}
\subsektion{Naming and identity verification}
\textbf{Zooko's Triangle}\\
For any naming system, you want it to be unique, human-memorable, and decentralized. Pick 2, because you can't get all 3.
\begin{example}
Real names are not unique. Domain names are not decentralized. Onion addresses are not human memorable.
\end{example}
\textbf{Two types of certs}
\begin{enumerate}
\item \textbf{Domain Validation}\\
The standard name = DNS name (domain) way of issuing certificates. It's usually automated and email-based.
\item \textbf{Extended Validation}\\
You see the name of the entity behind the url (eg. Microsoft). Browers show you the name in the URL bar and/or a green lock. The browser doesn't need to check the url in this case.
\end{enumerate}
\subsektion{Anchoring}
Which roots should you trust? If you can issue certs, you can run MITM attacks on certs.
\subsektion{Revocation}
This is different from expiration (which is for normal key hygiene). It involves
\begin{enumerate}
\item Authenticating the revocation request
If you're not careful, it is an easy DOS! Also can't ask for an old key because the entity might not have it.
\textbf{Solution:} Sign a revocation request every time you get a new key and ``lock away'' this request. If anything happens, you can send the revocation request.
\item Keeping clients up to date
\textbf{Offline model:} Certificate revocation list; issue an ``anti-certificate''
\textbf{Online model:} OCSP (online cert status protocol) is a CA's server that can be queried for certificate statuses in real time
\end{enumerate}
Note that revocation often fails in practice. Most browsers only check for EV certs, which can be 6 months out of date.\\
So what happens when a CA doesn't respond? What should your browser do?
\begin{itemize}
\item Can't just not give you access; this would mean that the entire internet is broken when CA is down.
\end{itemize}
Sites like Facebook are probably better at keeping their site up than VeriSign. Also, it's an easy DOS attack to take down a CA.
\textbf{Result:} Browser just goes ahead if CA is down.