# Public Key Certificates - Ucccs.info

Τεχνίτη Νοημοσύνη και Ρομποτική

21 Νοε 2013 (πριν από 4 χρόνια και 5 μήνες)

113 εμφανίσεις

HTTPS

Network Security

An untrusted public network.

Problems: Eve eavesdrops on network packets, Eve modifies network

packets, Eve injects
messages pretending to come from Alice/Bob, ....

Confidentiality
-

Data cannot be read by unintended recipients;

Integrity
-

Data cannot be altered without detection;

Authentication
-

Data attributed to correct originator;

Cryptography

A cryptographic cipher is a pair of Encrypt and Decrypt algorithms such

that given plaintext
P, encryption key K1 and decryption key

K2 then

D(K2,E(K1, P)) = P

In absence of knowledge about K2, it must be not be feasible to

recover P from the
ciphertext E(K1, P).

Given P and E(K1, P), it must not be feasible to recover K1

Note that the plaintext P can be any data, including plain te
xt.

We call E(K1, P) the ciphertext.

Symmetric/Secret key cryptography: K1 = K2;

Public key cryptography Cryptography: K1 6= K2

Secure Communication

Bob (browser) wishes to communicate securely with Alice (web server).

If Alice and Bob share a secret

symmetric encryption key KAB then

B → A : E(K
AB
,message(eg credit card details))

and A can decrypt the message as

message = D(K
AB
,E(KAB,message))

A can also use K
AB

to send data securely to B

A → B : E(K
AB
,message)

If B can be sure that they only other
pri
ncipal who knows the secret key
KAB is A then he
ding credit card details to the
web
-
server.

However, how does A and B come to share the secret key KAB?

Authentication

Suppose that A has a (encryption) pu
blic key KA and a
corresponding (decryption) private
key K

A

1

where D(K
A

1

,E(K
A
, P)) = P and that A’s
public key is widely known.

If B knows that A’s public key is K
A

then B

could first propose a random
key K
AB

and send it
securely to A using

B → A : E(K
A
, [K
AB
...])

B
knows that the only principal who can d
iscover his proposed secret key
K
AB

is A since only
A knows

the private decryption key K
A

1
. Therefore,
after the above exchange B can be sure
that only K
AB

is known to A.

This is a very simple example of a secure

ke
y exchange protocol: the two
parties exchange a
series of messages,
after which they share a secret
symmetric key.

It is also a very simple variation of the SSL/TLS protocol.

HTTPS = HTTP + SSL

The HTTPS protocol uses SSL/TLS to es
tablish a shared secret

key KAB
between a browser B
and a web
-
server A
. One the key exchange protocol
has completed then all subsequent
HTTP requests and

responses are
encrypted using this key.

Public Key Certificates

How does the browser B come to learn that A’s public key is
KA?

A public key certificate is a statement that is issued a
nd signed by a trusted
third party
declaring that a given principal

(eg A) owns a given public key
(eg K
A
).

This trusted third party is called a Certific
ation Authority and the CA uses
its own p
rivate key
to ‘sign’ the certificate. This signature can be co
nfirmed
by anyone who knows the CA’s
public key.

A browser contains the public keys of a

number of well
-
known CAs. When
a browser first
connects to a web
-
server
over HTTPS the server sends its
certificate, and if it is signed by a
CA that
the browser recognizes then the
browser can continue the protocol and establish
the shared key.

Msg 1

B → A

hello

Msg 2

A → B

certificate for K
A

Msg 3

B → A
E(K
A
, [K
AB
...])

Msg 4

A → B

E(K
AB
, success...)

X500 Names for X509 Certificates

We need to be able to uniquely name
principals if we are to support
universal certificates
that bind principal (identities) to their public keys.

X500: A proposed hierarchical naming

scheme. The intention was that
X500 Distinguished
Names can be use
d to give a guaranteed name for
everything in the world!

C=country,

S=state,

L=locality,

O=organization,

OU=organization unit,

CN=common name,

. . .

X500 DNs are used to name principals

in X509 certificates.

X509 PKI in Practice

No clear plan on how to organize X500 dir
ectory in reality: hierarchical
naming suits military
and government but
does not work for businesses or
individuals.

In practice, we have just one hierarchy pe
r organiz
ation and/or have many
commercial CAs
that sign certificates for each

other and for other principals
such as UCC and for individuals.

How does Alice learn Bob’s public key?

Alice knows and trusts a number of roo
t
CAs: eg, verisign.

Route from
CA Alice trusts to Bob provides
certificate chain.

Some C
As only certify end
-
principals:
note the dan
ger of delegating to customer’s
CA (must
be trusted to delegate).

HTTPS in the Browser

We use the protocol https://www.foo.bar
.com to indicate a desire f
or a
secure connection
from the browser to the web
-
server.

The secure connection is successful if the c
ertificate is accepted as valid
and that web
-
server
demonstrates that it
can decrypt the key proposed by
the browser and that the Common
Name CN

in the
cert matches the domain
in the URL of the request/response.

This is a secure authentic connection.

Browser gives an indication if the secure connection is successful

Don’t embed HTTP content in HTTPS

If a page loads over HTTPS, but it includ
es some content that loads over
HTTP then

Browser (IE7/Firefox3) does not display lock and/or gives a warning

to the user.
(Safari does not detect mixed content).

However, embedded flash does not give this warning. Thus, a

programmer error
<embed src=http:
//www.bank.com/anim.swf>

in an HTTPS web page might be
exploitable by an attacker!

Regardless, to be safe, should avoid spec
ifying the protocol in embedded
content. <embed
src=//www.bank
.com/anim.swf>

Don’t embed HTTP
S

content in HTTPS

The

web page is http, however, its
HTML source contains a form

<form method= "post"

action="https://onlineservices.wachovia.com/..."

A visitor using http does not know whether

they are actually visiting the
wachovia.com
website or some site m
therefore does not know where
their login credentials are being sent.

A request to http://wachovia.com shou
ld have resulted in a re
-
direct
response to
https
://wachovia.com where the user can then enter their

credentials. The visitor should be
able t
o ’see’ that they have a secure
connection to the website they expect.

Flaws in the HTML

An old version of https://www.onsale.
com used GET for sensitive form
attr
ibutes; on some
early browsers

the URL was not secured by SSL
(though the contents of the page were).
Regardless, its best to do a POST.

Many examples of errors in the html:

-
server with only 40
-
bit crypto enabled.

Verisign once forgot
the ’s’ in an http reference to a page where user

provided
userid/pin.

...

Modern browsers like Firefox provide

a range of checks for possible
‘mistakes’. However, it
is ultimately the user’
s responsibility to ensure that
the connection is secure and to t
he right
website.

Semantic Attacks

An attacker registers the website

amason.com and obtains a valid
certificate that associates
their public key w
ith that website. Valid secure
connections can be made by the browser to
https://www.amason.com.

A browser
user might be confused about the domain of

Recall the GBK Chinese character set. It includes characters that l
ook like
/, ?, . and =.

Attacker owns domain evil.cn and gets a cert for *.evil.cn

Attacker sets up a
sub
-
domain

How is the ?u interpreted?

A browser visiting this web
-
site under https has a valid secure

connection to (a sub
-
doma
in of) evil.cn, however, the user of the

browser probably thinks they are visiting
www.bank.com
.

Extended Validation Certificates

A conventional certificate makes few claims

about the true identity of the
owner of a
website.

An extended validation certificate requi
res a human lawyer at the CA to
validate the identify
of the individual re
questing the certificate. These
certificates are indented for highly secure
connections such as banks.

Look at http://verisign.com
and
http://paypay.com

Man in the Middle and Elsewhere Attack

Attacker sits between bank.com and user browser.

Attacker masquerades as bank.com to user browser.

User browser unknowingly connects to attacker via HTTP,

Atta
cker connects to bank via HTTPS

Attacker masquerades as bank.com to user browser.

User browser mistakenly connects to attacker via HTTPS,

Attacker connects to bank via HTTPS

Problems with accepting invalid certificates

If the browser user is niave

and is willing to a
ccept invalid certificates then
the browser user
will be subject to a man
-
in
-
the
-
middle attack.

Suppose that a malicious third party (bunk
.com) resides on the connection
between the
browser and a web
-
server.

The browser sends an https

conne
ct request to bank.com. This is
intercepted by the man in
the midd
le who passes the request on to
bank.com.

The man in the middle responds
bank.com but with an
invalid certificate (issued to bunk.com.

The browser war
ns the user that the certi
ficate is invalid as its Common
Name CN does not
match that of the
URL (bank.com) that the user is
requesting.

If the user accepts the invalid certificate then the man
in the middle has a
secure connection
to the user and a secur
e

connection to the bank and can