Slides with notes - front page fontysvenlo.org

Transcription

1. Crash course on security of web sites
2. How it is practiced in internet land Holland
teus hagen <[email protected]>
Software Engineering Colloquium Spring 2011, Fontys Venlo
Venlo, 16th of February 2011
Software engineering Fontys Venlo, 16th Februari 2011, Teus Hagen, ”on the SSL/TLS security of web sites”
66 slides minus 2 to go
on the client side you think you can hide as a dog
is that really so?
args:
1. can do browser finger printing (not yet much practiced)
2. server can detect open mail channels eg gmail channel
what about using a logo (html picture) in the email to signal reading the email?
extend this email idea with the script idea of the browser server?
script details:
https://grepular.com//Abusing_HTTP_Status_Codes_to_Expose_Private_Information
"network.dns.disablePrefetch" boolean value "true"
Firefox: add this in about:config for counter measurements
security engineering
from the book “security engineering” of Ross Anderson
+
M
-
design A
M
+ -
design B
look what is the difference picture
which of the two is better?
electr. short cut possible with which one!
content
⧫
lessons to be learned from the physical key-lock world
⧫
crash course on encryption, digital signatures and digital certificates
⧫
internet land protection layers:
DNS, with DNSSEC the key to identify end points
SSL/TLS client and server security configuration
⧫
SSL/TLS Assessments of Dutch web sites
internet banks, governments, education, e-commerce, health-care,
security firms.
⧫
basic conclusions: only three
Content
- development of locks in the real world
- encryption, hashing and certificates how they work
the basic howto knowledge example RSA
- DNSSEC status, statistics
- SSL/TLS what it is about
- amazing statistic figures,
this does not make you make friends
- three items on the TO DO list
of Neelie Kroes
and you
good books on security within IT
⧫
theory:
∘
⧫
⧫
implementation:
∘
Cryptography Engineering, Ferguson, Schneier, Kohno (ed 2010)
∘
Modsecurity Handbook, Ivan Ristić (rev 2010)
∘
Apache Security, Ivan Ristic (2009)
history and practice:
∘
⧫
Applied Cryptography, Bruce Schneier (2nd ed. 1996)
Security Engineering, Ross Anderson, (2nd ed. 2008)
non-technicians:
∘
Beyond Fear (thinking sensible), Bruce Schneier (2006)
∘
Secret & Lies (with post 9/11 info), Bruce Schneier (2000)
Theory book, 15 yrs old book, only if you know howto math?
crypto book is the howto, a recent book, many detailed algorithms
Ivan Ristic is the Apache security fellow, books can be ordered as ebooks
Ross Anderson is prof. First edition is freely downloadable but is old
ed 1 has 600 pages, ed 2: 1000 pages....
how to live with fear, remain to be practical
Security in the physical world:
keys and locks, authenticate and disclose
⧫
yr 1778: double lever tumbling locks
ca 10 bits strength
⧫
yr 1844: cylinder / pin locks
ca 20 bit strength
⧫
yr 2000: physical locks getting digital
ca 128 bit strength
- 2-levers 4 blades 15 euro lock
Chubb invented blocking of night lock,
lock picking, 'runner key', 50 euro via web site order
- cylinder pins 4-6, some more sided, 35 euro lock
Yale invention
lock picking is like music, an art to tell a story
bumping, Chaos conf. (Treffen) Berlin 2004
95% of locks open easily
- Winkhaus 128 bit digital driven lock, 450 euro lock
hacking: easy to do with magnet
Howto hack:
brute force always the easy way,
burglar way (Bulgarian Baco trick)
social engineering a definite go (key below the carpet)
have good survey done (open window, unlocked door).
- Stichting Kwaliteit Gevels cerificate (keurmerk) with stars,
so there is some form of accreditation
hacking in the physical world
locks of cars are usually better, but
e.g.
Electronic Control Unit ECU
allows you
to control your car
from a distance
so can be hacked
- locks of cars are better quality as locks of doors
- July 2010 Experimental Security Analyzes of a Modern Automobile
- Karl Koscher on IEEE Symposium
- it gives full remote access to the vehicle
speed 120 MPH, gear is in R (neutral), message notice with title paper
- Black Hat July 2010:
showed how to make the ATM pay you dollars
via the remote monitor function
- remote control is overlooked most of the time
what can be learned from all this?
⧫
protection arrangements relate to value goods
⧫
every security technique has limited time of life
⧫
all can be hacked, usually via unexpected routes
⧫
security certification is the driving force,
but only with non-commercial interest
⧫
authentication is complex and is difficult
- locking can break emergency exit arrangements!
- evolution of internet is 100 times faster as physical world
- internet world is big, bigger, biggest
and mostly anonymous, so w're all dogs
- are the precautions practical,
can one maintain them?
- 1. IDENTIFY
identify computers: client and server
- 2. AUTHENTICATE owner via certificates both ends
- 3. PROTECT COMMUNICATION privacy
via encryption and integrity control:
sender (hash function)
crash course
⧫
encryption (RSA)
⧫
digital signatures (RSA,SHA)
⧫
digital certificates (X.509)
only the very basics
few elements you need to know
to understand applications and behavior
to separate uncertainty from unclearness
encryption
⧫
rotor machine invented by
Hebern (Germany)
⧫
later Enigma
Second World war
A bit more clever trick as Ceasar encryption, but still similar
note that Enigma was hacked in 1932 by Polish Cipher Bureau
Hebern patent in 1918, others followed at that time already
how encryption works
so the start point was the password
rotor positions were also in the password
extra trick:
position of cylinder (n positions) to change after
every char encryption to avoid statistical hacking
encryption needs
⧫
⧫
the encryption elements:
∘
(pseudo) random numbers
∘
primes (1024-4096 bits)
∘
hash function (no collisions -> birth date paradox)
number theory
∘
project (1-1 function) number into finite space
∘
calculations in finite space
RSA (Rivest-Shamir-Adleman) 1978
⧫
primes : p X q = n (mod n) (n > 1000 bits)
⧫
⧫
⧫
t = (p-1) * (q-1)
⧫
⧫
⧫
t = (p-1) * (q-1)
⧫
random encrypt key e such that gcd(e, t) = 1
or
e X d = 1(mod λ) where λ = lcm(p-1,q-1)
⧫
this is called 'relatively prime' or coprime
alternative is d X e = 1 mod phi where phi = lcm(p-1,q-1)
⧫
⧫
t = (p-1) * (q-1)
⧫
⧫
decrypt key d such that e X d = 1 (mod t)
⧫
⧫
t = (p-1) * (q-1)
⧫
⧫
⧫
encrypt message m: me (mod n) -> c
⧫
⧫
⧫
t = (p-1) * (q-1)
⧫
⧫
⧫
encrypt message m: me (mod n) -> c
⧫
decrypt c: cd (mod n) -> m
proof: (me)d = med = mkt+1 = mkt.m = (1)k X m
real life example RSA
⧫
primes p = 11, q = 3 ->
⧫
t = (11-1) X (3-1) = 10 X 2 = 20
⧫
choose random e = 3
-1
such that gcd(e,t) = gcd(3,20) = 1
⧫
d=e
⧫
encrypt message m = 7 (needs e,n) ->
(mod t)
=3
-1
n = 11 X 3 = 33
(mod 20)
-> (try 1, 2, 3, ...., 7) -> d = 7
me(mod n) = 73(mod 33) = 34333 = (330+13)33 = 13
⧫
decrypt c = 13 (needs d,n) (d needs e,p,q) ->
cd(mod n) = 137(mod 33) = 133+3+1 33 = 219733.(66.33 + 19)33.1333
= (19.19)33.1333 = 36133.1333 = (330+31)33.1333 = 40333 = (396+7)33= 7
RSA is very bad on small n
Not better as Ceasar encryption
RSA is bad on two messages on similar encryption key (signatures)
So add random noise to signature or even message
See http://www.di-mgt.com.au/rsa_alg.htm for more details on this example.
RSA was patented however patent expired now.
real life example RSA
⧫
primes p = 11, q = 3 ->
n = p X q = 11 X 3 -> n = 33
⧫
t = (p-1) X (q-1) = (11-1) X (3-1) = 10 X 2 -> t = 20
⧫
choose 'random' e = 3
⧫
d = e-1 (mod t) = 3-1(mod 20) -> (try 1, 2, 3, ...., 7) -> d = 7
⧫⧫
decrypt
c = 13 (needs
(d needs
e,p,q) ->
encrypt message
m = 7d,n)
(needs
e,n) ->
such that gcd(e,t) = gcd(3,20) = 1
7
e
cmd(mod
n) = 13 3
= 133+3+1 = 219733.(66.33
.1333
(mod n) = 7 (mod 33) = 343 33= (330+13)
-> +c 19)
= 13
33
(mod 33)
33
33
= (19.19)33.1333 = 36133.1333 = (330+31)33.1333 = 40333 = (396+7)33-> m = 7
RSA is very bad on small n
Not better as Ceasar encryption
RSA is bad on two messages on similar encryption key (signatures)
So add random noise to signature or even message
See http://www.di-mgt.com.au/rsa_alg.htm for more details on this example.
RSA was patented however patent expired now.
public and private encryption key
⧫
pub key: (n,e)
n = p X q primes
⧫
private key: (p,q,t,d)
t = gcd(p-1,q-1)
⧫
choose e 'random' such that e X d = 1 (mod t)
hash function
function to map number i to f(i) in N-space
there is no f-1 function, so no 1-1 function
N-space is big enough, say 256 bits
no collision allowed
birth date paradox
How many people do you need to have
50% chance on two persons birth date on same day?
Paradox: estimation amount of people are far higher as reality shows
This shows risk of collisions are high!
digital signature
⧫
⧫
⧫
sign message:
∘
hash message m -> number 256 bits
∘
add random bits -> number of say 1M bits
∘
encrypt number with private key
∘
add encrypted number to the message
check signature:
∘
decrypt dig. signature (number) -> hash value
∘
hash message (same value?)
rely on: public key belongs to the sender of the message
Message is small
Message has structure
So we need random bits to add
digital signature
comments on encryption and hash functions
⧫
⧫
hash functions used for signatures
∘
MD5 (Ron Rivest) is broken
∘
SHA-1 (Secure Hash Algorithm; NSA; omit from today
∘
SAH-224, SHA-256, SHA-384 and SHA-512 (NIST)
encryption functions
∘
DH (Diffie-Hellman) 1976
⁌
∘
Man In The Middle (MITM) problem
RSA (Rivest, Shamir, Adleman) 1978 (n > 2048 bits, 20 years)
⁌
small size problem eg with signatures
⁌
mathematical structure problem
with 2 signatures, compute sign. on message 3 as: s3 = s1.s2 (mod n)
hash function
No collision allowed, why?
Birth date paradox (next slide)
MD5 is harmfull. A hack was expected and done.
SHA-1 2009 a collision was proofed, so Jan 2011 no sha1 anymore
DH weaker as RSA
RSA still problem on low numbers
Others ciphers: AES, DSA, and … elleptic curve
X.509 digital certificate
⧫
public key of individual or server
⧫
owner information
⁌
⧫
name, email or host name, owner 'details'
digital signature of Certificate Authority (CA)
⁌
validation of all information on certificate
⧫
revocation information, start & expiration date
⧫
allowed use of the certificate
⁌
⧫
login, code signing, EV, DV, etc.
standard: X.509 (or e.g. another std PGP)
X.509 have no public key service as PGP
X.509 is hierarchical structure via signatures
X.509 rely on one authority
maybe idea of web of trust via agents or users
X.509 info validation is doubtful due to
economics and culture difference (law, trade, social culture)
how to get a trusted CA list?
e.g. Ubuntu validates Verisign?
what if a CA is becoming distrusted? (no warning system)
PGP web of trust: rely on many agents, there is trust factor
what about server cert fingerprint in DNS(SEC) record?
www.startcom.com provides free certs
CAcert too but is not in CA mainstream
X.509 client
certificate
⧫
Click to add an outline
the HowTo
thunderbird certificate management
X.509 certificate
what to look for
⧫
Common Name (CN)
⧫
owner, does it match what you think it should be
⧫
domain and alt names (defined, no wild cards)
⧫
DV (domain validated) or EV (owner validated)
⧫
signature CA (trusted?, no MD5, SHA-1 is deprecated)
⧫
expiring within < 1-2 years & expired already?
⧫
at least one revocation method/address, pref. OCSP
⧫
private key well protected, and made by the owner!
Wild card e.g. : *.shell.com (do not accept this!)
Server cert should have host name(s)
Common Name (CN)can be:
e.g. Teus Hagen, client cert email [email protected]
or server cert www.site.com
Organisational Unit (OU) not needed. Usual empty (cannot be validated)
Similar for country and address.
check own cert for capabilities: login, code signing, etc. the trick to collect a lot of
money by the CA
Alt Names: 1 or 2, not 43!
X.509 certs are on the chip of ID (passport, driver license, etc.)
what we learned so far
⧫
the security practice with locks
ease of hacking,
dependency of policies
PAUSE
enforcement
validation and evaluation
⧫
theory of security in digit land
⧫
security tools in digit land
10 minutes
use them, configure them
server side and client side
browser  server: how it is protected
(1) URL : the host name
➔
DNS map host name to IP address
➔
DNSSEC secures this
(2) next get server document
➔
secured via HTTPS or better SSL/TLS
do this also for:
protected email, terminal access, VPN, etc. etc.
ideally DNSSEC is enough for this
signatures are proof to identity information
in practice we should use both, and so more complicated
encryption, more theory
⧫
⧫
the encryption elements:
∘
(pseudo) random numbers
∘
primes (1000-4000 bits)
∘
least common multiples of prime minus 1
∘
hash function (no collisions -> birth date theorem)
number theory
∘
project (1-1 function) number into finite space
∘
calculations in finite space
1. DNSSEC: is the IP address really you?
⧫
July, 2010:
first firm step with signing the DNS Root;
⧫
DNSSEC statistics October 2010:
60% have software ready;
⧫
DNSSEC test October 2010:
only 3% really use it;
⧫
test October 2010:
only a very very few entries are secured by DNSSEC
- DNSSEC relies on signatures
- registrars do not validate info up to today
discssions to validate not yet started
- evaluation which ISP had the software ready:
about 60%
- RIPE did made available a test:
also 60%, an
XS4all was not ready!
- however
what about the ADSL/routers at home.
BSI study 36 home routers covering
90% of the market,
only 4 were ready!
how end users surf:
the host name in URL
- does anyone know this?
what does the key with the stop signal means?
- who has that in their browser?
- it is an Firefox add-on, have a look for it: DNSSEC
DNSSEC show IP - host name validation
⧫
- waiting for validating
- resolver can be adjusted via preference
csrc.nist.gov
2
12
www.icann.org
2
15
www.isc.org
2
15
www.abnamro.nl
www.digid.nl
www.sidn.nl
1
1
2
3
3
3
www.nlnetlabs.nl
2
3
8
www.nluug.nl
www.surfnet.nl
2
2
4
3
4
7
www.cacert.org
1
www.nunames.nu
4
4
4
15
1
8
d e le
se c g a t io
ur e
d n d e le
ins g a t io
ecu
re n RRs
se c e t ure
d
RRs
ins e t ecu
re
DN
/N S SKE Y/D
E
S
se c C ure
d
DN
/N S SKE Y/D
S
ins EC ec
s e c ure
a lg urit y o rit
hm
dom
na m a in e
DNSSEC configuration status in more detail
RSA/SHA1 (4) RSASHA1-NSEC3-SHA1 (3) RSA/SHA256 (2)
RSA/SHA256 (5)
2
1
3
4
2
2
2
RSA/SHA256 (5)
RSA/SHA256 (5)
RSA/SHA1 (2) RSA/SHA256 (7)
RSA/SHA256 (5)
2
RSA/SHA256 (8)
4
2
3
1
2
1
Oct 2010
- Sandia DNS Visualization validation tool
October 2010
- 6 cipher/hash suites used 4
should be phased out: MD5 and SHA1
- ICANN and ISC of course,
but notice the SHA1 use!
- Holland is still far away.
- After some interactions
CAcert play their own game (Wytze thanks!):
they use DNSSEC DLV trick
via ISC consortium.
- It's still a long way to Tipperary
DNSSEC conclusions
⧫
it's still a too
long way to Tipperary ...
⧫
but with some tricks we can shorten travel time
⧫
end user should install more validation signals
⧫
DNSSEC is however only the first step:
secures network address and host/domain name
⧫
also give every instance of an individual
an IPV6 address?
it steps silently over
the binding of the end user
to his end point on the network
public wifi is secured? (MITM tactic)
home routers and modems are troublesome
but know your DHCP is not secured by your ISP
who is using IPV6?
maybe the VDSL2 introduction helps (new DSL modems streamed in today)
2. SSL/TLS protocol layer: identify/authorize
2.1 first identify / authenticate:
use the X.509 certificate
₀
match validated host/domain name <-> IP address
₀
match owner ...
₀
Info validated by the Certificate Authority (CA) (?)
₀
check trust of the CA
2.2 ...
- support needed from DNS
to know who you say you are,
and you are talking to
- is this the domain name
you wanted to talk to?
- host names, domain names
do not say much
if they are not on the certificate
- or are wild cards
- sloppiness needs proper identification
from owner
- BUT user should identify himself
also properly: individual certificates:
- Web ID, OpenID
- be aware of your traceability
- browser fingerprinting can easily be used
Certificate Authority (CA)
⧫
- who you are, you say you are
- CAcert:
added on CA accepted list, so blue,
owner unknown
- Venray.nl:
local governement e-desk,
owner unknown,
no EV certificate,
not trusted
- ICANN:
accredited
owner unknown
no EV certificate
- Verisign:
EV certificate,
owner known
but: self signed! All CA's do this
- EV certificates are sometimes on sale:
ca 100 euro per year, so expect not much
validation doubtful
“Say what you do,
do what you say,
prove it.”
David Ross
⧫
accreditation of CA' s
is sloppy
⧫
certificate applications (configurations):
not assessed, no check!
⧫
names on certificates
conclusion:
are hopeless
certificates give false sense of trust
- in commercial hands
– should Ubuntu require
audit for Verisign?
- David Ross criteria
- most CA's are based in the US
and operate from there
far away is a jurisdiction problem
there is a market culture problem:
buy a cert showed:
need entry phone book
or lawyer/bank director
for name validation?
Chambre de Commerce (trade)
KvK Nld is most advanced in EU
do not expect much is done for your 100 euro
David Ross (Mozilla) Criteria for a CA
DRC reference(s) Title / Area Comments A.1 Configuration-Controlled Specification (CCS) This is effectively the list of controlled documents that the audit insists is in place.
A.2-3 Certification Practice Statement and Certificate Policy The core technical rules of the CA. A.4 Privacy A.5 Security Manual DRC expects security details to be extracted from CPS/CP. A.6 Risks, Liabilities short list of disclosures. B Access for Subscribers, and "the General Public" short list of disclosures. C.1 Documentation Conformance "The CA has been repeatedly observed to operate in general conformance with its CPS." C.2-4 Security, Maintaining Root Certificates "The root certificate private key is stored secure from electronic and physical compromise." C.5-8 Generating / Signing / Renewing / Revoking "Certificates are signed in a timely manner" C.9 Use of External Registration Authority "RAs provide the CA with complete documentation on each verified applicant for a certificate (see &A.2,w)" Software engineering Fontys Venlo, 16th Februari 2011, Teus Hagen, ”on the SSL/TLS security of web sites”
overview of criteria for acceptance of CA
in Mozilla
why should a browser firm do this?
2. SSL/TLS protocol layer: choose encryption
2.1 identification / authentication: X.509 certificate
∘
match host/domain name <-> IP address
∘
match owner
∘
Checked by Certificate Authority (CA)
2.2 negotiate and establish cipher suite:
⧫
∘
encryption algorithm (hide) and
∘
hashing function (validate)
need configurations on BOTH end points
- hashing function MD5 is harmful
already more as a year now
how many persons needed for birthday collision?
50% chance of collision
- SHA1 only till end of 2010
statement of Bruce Schneier
- insecure ciphers
- insecure renegotiation (MITM possibility)
- too many own invented algorithms
are still around
SSL/TLS configuration on both end points
⧫
end-user end: Firefox
⧫
server side configuration, the internet security policy

∘
e-banking: PCI DSS-2
∘
e-commerce FIPS 140-2
tools: check and assess it!
openssl, sslscan, sslsnif, ... www.ssllabs.com
- PCI DSS -2 sloppy requirements:
Payment Card Industry Data Security Standard
only strong ciphers
for banks, initiated credit card companies
easy to implement
- FIPS 140-2:
especially for e-commerce
Federal Information Processing Standard
much more detail
MD5 is out, SHA1 is just still in
but nobody implements them....
- there is no certifying/marking (waarborg) body
in Holland who checks/assesses
- paper has full details and suggestions
- it is so easy to get things
on an acceptable level
- reminder: if you scan arrange:
null-MD5, the lock shows “locked”.
- Use: Apache Security and Modsecurity Handbook, Ivan Ristic publ Feisty Duck
SSL/TLS configuration what to look for
⧫
X.509 cert OK? Name matches with DNSsec server name?
⧫
no MD5, and SHA-1 is deprecated
⧫
minimal 1024 bits
⧫
no SSL V2 usage at all
⧫
no (insecure) renegotiation
⧫
SSL Labs ratings >= 85%
⧫
ephemeral DH support
⧫
no MITM (man in the middle) possibility
⧫
adjust browser configuration for acceptable cipher level
⧫
not any of weak or insecure encryption/cipher
Ephemeral DH:
also when data is recorded and saved
no used encryption key recovery is possible
SSL/TLS assessment
of ca 200 Dutch web sites
categories / branches:
⧫
on-line banking (29)
⧫
governmental: central, regional, local (37)
⧫
e-commerce: trade, services (44)
⧫
health care (41)
⧫
education: universities, academics, colleges (25)
⧫
internet security consultancy and services (19)
- values are not statistical solid (not random selection and check)
- all assessments figures from SSL Labs (Qualys)
- how: convert HTML SSL Labs data into spreadsheet data/formula
- tried to send all assessment values to web site manager (twice):
end of July and 31 October 2010
the feedback/response was minor, eg
email from “postmaster” that “user postmaster did not exists”
“you will get an answer within 24-48 hours, ticket number NNN”
you are the internet police?
anyhow those who are personally known to me reacted
- but nevertheless some did update the config (DigiD)
healthcare: thanks to blog health care
this shows that it can be done easily
NLnetLabs and CAcert went so on top
general picture of the SSLLabs assessments
2011, 28th January
statistics of 2010, 31st October
SSL Labs rating for all
SSL Labs rating for all
A is high, F is low
A is high, F is low
43
58
A
B
C
D
E
F
23%
40%
9%
25%
A
B
C
D
E
F
15
46
6
average ratings
blue color: >80%
- cipher strength
- key exchange
- protocols offered
- server cert is the CA trusted?
- expired cert
- insecure cipher use
- renegotiation (MITM?)
Cross Site Request Forgery – CSRF
use only encrypted cookie as parameter
- insecure session resumption
3%
the figures of all categories in more detail
2011, 28th January
statistics of 2010, 31st October
SSL Labs ratings per category
SSL Labs ratings per category
A is high, F is low
41%
A is high, F is low
39%
44%
30%
36%
24%
rating
16
14
12
27%
26%
25%21%
63%
44%
54%
A
B
C
D
E
F
25%
16%
20%
10
38%
8
13% 25%
0%
25% 6% 3%
0% 0%
6
4
2
13%
13%
0%
12%8% 8%
2%
0%
C
A
edu
i_sec
E
D
B
0
F
E-shop
i_bank
health
E-gov
%
%
18
36%
16
14
12
18%
10
32%
8
4
0%
2
- healthcare worst
- education worry some
- e-commerce trouble, a mess,
No marking, only on trade
5%
3%
A
B
C
D
E
F
15%
23%
11%
2%
2%
F
0%
7%
E
D
0%
C
B
A
0
edu
i_sec
- banks, I sec differ from rest
18%
18%
rating
13%
12% 15%
0%
6
categories
- per category
27%
27%
71%
32%
50%
35%
29%
E-shop
i_bank
health
E-gov
categories
79%
59%
59%
69%
58%
77%
69%
74%
49%
53%
57%
47%
76%
62%
83%
64%
63%
71%
63%
80%
73%
53%
18%
33%
42%
37%
44%
35%
100%
100%
100%
100%
100%
100%
100%
88%
100%
100%
100%
100%
100%
99%
88%
100%
100%
100%
100%
100%
99%
- average rating, all should be >80%
- CA trusted, all >80%
- protocols:
protocol rating
key exchange rating
cipher rating
- protocols
SSL2 should be out, zero
- PCI DSS 2 / FIPS 140-2
Fedral Information Processing Stabdard
- no weak cipher strength
>128 bits, > 10 minutes computer power
19% 75% 13% 69% 0% 19%
73% 88% 42% 9% 0% 73%
75% 100% 38% 25% 0% 75%
36% 83% 21% 31% 0% 60%
71% 92% 21% 25% 0% 75%
26% 87% 22% 65% 0% 17%
46% 100% 26% 40% 0% 51%
phs
hs
# ins
ec cy
k cyp
read
y
# wea
nt
FIPS
ompl
ia
eg.
PCI c
insec
ure r
en
resum
ption
sess
ion SSL 2.0
SSL 2.0+
SSL 3.0
TLS MITM
r
?
1. 0
n ge
xcha
80%
63%
63%
73%
63%
76%
72%
ciphe
col
81%
59%
88%
76%
88%
75%
76%
key e
proto
category
i_sec
healthcare
edu
e-shop
e-gov
i_bank
all categories
CA tr
av. ra
ting
usted
all categories in much more detail (Oct 2010)
6%
3%
0%
5%
4%
0%
4%
i_sec
77% 82% 80% 70% 83% 56% 33% 0% 0% 100%
76%
12% 71%
0% 18% 12%
healthcare
61% 64% 63% 53% 68% 20% 27% 0% 0% 100% 100% 100% 73% 100%
24% 15%
0% 67% 3%
edu
59% 88% 63% 53% 63% 33%
0% 0% 0% 100% 100% 100% 75% 100%
38% 25%
0% 75% 0%
e-shop
71% 78% 77% 63% 74% 37% 33% 0% 0% 100% 100% 100% 27% 100%
17% 32%
0% 51% 2%
e-gov
59% 86% 64% 50% 64% 35% 14% 0% 0% 100% 100% 100% 69% 100%
14% 21%
0% 76% 0%
i_bank
78% 77% 77% 77% 81% 45% 52% 0% 0% 100% 100% 100% 24%
84%
24% 68%
0% 21% 0%
state 2011/02
69% 76% 72% 62% 73% 35% 30% 0% 0% 100%
99% 46% 100%
25% 40%
0% 51% 4%
99%
- average rating, all should be >80%
- CA trusted, all >80%
- protocols:
protocol rating
key exchange rating
cipher rating
- protocols
SSL2 should be out, zero
- PCI DSS 2 / FIPS 140-2
Fedral Information Processing Stabdard
- no weak cipher strength
>128 bits, > 10 minutes computer power
88% 18%
s es
r e s s i o n um
pt io
n
in s
e
r e n c u r e eg .
PCI
c o m plia
n
FIP
S r e t
ad y
# w
c y p e a k hs
# i n
c y p s e c hs
S SL
2 . 0
+
88%
SSL
2 . 0
SS L
3 . 0
1 . 0
1 . 1
T LS
T LS
pe
1 . 2
t t y
ce r
T LS
M?
M IT
key
e x c h an
ge
c ip
h er
ol
st e
toc
p ro
t ru
r a t
av .
ca t
C A eg o
ry
ing
d
all categories in much more detail (Feb 2011)
internet banking (29 sites assessed)
high lights
⧫
ING – mijn.postbank.nl
SSL Labs rating for internet banking
A is high, F is low
NIBC – www.nibcdirect.nl
9
redirect, expired certificate
⧫
Staalbankiers en FBA
expired certificate, no EV, 40 bits
⧫
14
3
2
Bank of Scotland en Kasbank
no domain name, no EV cert
⧫
Ideal
C rate, no EV/DV certificate
✗
79% allow insecure renegotiation (MITM)
- ING
www.ing.nl, mijn.ing.nl, mijn.postbank.nl
redirect without notice
expired certificate
- NIBC
redirect naar sparen.nibcdirect.nl without notice
gap of 6 weeks from expired and
low level SSL/TLS arrangement
- Fortis, FBA (much improved lately) and Staalbankiers
expired certificate, no EV certificate, allow 40 bits
- Ideal
only at C level, no EV/DV certificate
- SNS bank
connection failure, broke communication
A
B
C
D
E
F
government e-desks (27 sites assessed)
SSL Labs rating for gov. e-desks
high lights
⧫
DigiD (F rate -> A rate)
⧫
police (public office, locals)
A is high, F is low
3
4
2
A
B
C
D
E
F
5
11
Oct 2010
exp. (2yr) cert, 40 bits
⧫
SSL Labs rating for gov. e-desks
min. finances
A is high, F is low
C 48 % rate
⧫
A
B
C
D
E
F
e-court
only one with EV cert, but C 52 % rate
⧫
7
4
9
11
local gov: Venray, Horst ad Maas, Kerkrade,
Feb 2011
Peel en Maas, Gennep, prov Limburg
many self made, allow 40-bits
- Venray, Horst ad Maas
Self signed cert Cavernray
Horst was initially self signed
now Pink Rocade/Getronics week after complain
Local gov use all probably local host provider and web service provider
Anecdote: provider was right on corner, “who do you think you are!”
- Digid
Was F rate after publication is now OK, they use DigiNotar !
However still have key exchange problem
- police
Police Rotterdam (no domain name, no DV/EV cert),
Politie onderzoeken (OM) (use 2 yr expired cert)
two web sites: secured and unsecured web site
only 51% average
40 bit, insecure ciphers (with 21 on top)
- E-court only one with EV cert
21% PCI compliant:
tax, local Eemsmond, government, DigiD, Diginotar, land registry
e-commerce / web shops (44 sites assessed)
high lights
SSL Labs rating for web shops
A is high, F is low
12
13
⧫
A
B
C
D
E
F
providers:
Cornet (local cert), Ziggo (A, improved)
⧫
partner search:
Parship (A 85%), Relatie Planet (A 81% now)
⧫
1
18
Oct 2010
SSL Labs rating for web shops
A is high, F is low
web shops (20% no name on cert):
10
Wehkamp, Coolblue, Kwantum with EV
15
1
Pixmania (no security at all)
⧫
social networks:
Hyves (C 52% rate, allow 40 bits)
⧫
15
others:
BoF (A 88%), Consumenten Bond (C 52%, allow 40 bit)
- Cornet:
- Ziggo:
localhost certificate
A 85% improved from C 52% rate, still a wild card
- Parship:
A 85% min 128 bit, 5 weak ciphers
- Foreign Partner
not trusted certificate
- Wehkamp: A 88%, one of the two with EV cert
20% has no hostname on the certificate
- Hyves:
Only C 52%, 40 bits
Linkedin, Twitter are higher rates as all banks!
- BoF:
A 88% on top, but no EV certificate
- Consumenten Bond C 52%, allow 40 bit
- None is FIPS 140 compliant,
13 (23%) PCI compliant
1
Feb 2011
A
B
C
D
E
F
web shop certification / marking
- 16 web shop certification organisations
- 2 have applied for certification to
Council of Accreditation (ConsuWijzer)
- only Thuiswinkel reacted
but did not know what SSL/TLS is about
however Google showed a discussion in 2007
to do techn. Assessments
- ICTRecht only honest one?:
advise/help to adjust to all legal aspects
- all web sites searched for
techn security policies/requirements
none had them
approached all of them to ask
for correctness of omissions
health-care (41 sites assessed)
high lights
⧫
physicians
⧫
hospitals
⧫
GGD
⧫
EPN
⧫
health support
SSL Labs rating healthcare
7
2
- only a very few with A grading (with EV cert),
most had no hostname/domain name on cert
Improved: chat, digipolis, physician site, hulpmix
Most chat have now DV/EV cert
50% no name on cert
25% improved due to publications
- self manufactured certificates easy to find
- looking at RR host name record
one sees a lot of good willing help sites
- conclusion: money is better protected as privacy
A
B
C
D
E
F
A is high, F is low
5
13
1
13
A
Aug 2010 B
C
D
E
F
5
9
Feb 2011
internet (urgent) help and chat services
- Health care is the category to show
how bad it can be made
Some extra push done and it helped
A is high, F is low
Nov 2010
2
⧫
- 50% still use old fashioned login/password
without any protection
A
B
C
D
E
F
9
specialists
- Hard to find SSL/TLS protected web sites.
1
15
⧫
A is high, F is low
2
health care needs you!
business opportunity
Winfriet Tilanus <[email protected]>
education (25 sites assessed)
SSL Labs rating for educational
A is high, F is low
high lights
⧫
A
B
C
D
E
F
3
2
Oct 2010
CWI
no SSL, use wild card
⧫
2
University of Amsterdam
top!: A 84% rate, 128 bits, no SSL
⧫
1
TUE, VU, Nijmegen
SSL Labs rating for educational
A is high, F is low
7
6
40 bits, Terena CA
⧫
InHolland, NOVI, Fontys Venlo
one not secured, no name on certificate,
4
1
4
Feb 2011
allow 40 bits, insecure ciphers
⧫
Vertol, Adult University (Volksuniversiteit)
certficate expired, no name on certificate
- Universiteit van Amsterdam:
employee site, A 84%,
128 bits, no SSL 2
- CWI: A 88%,
wild card, no SSL2
- all others had 40 bits,
Terena has high market share in edu land.
- uni's: highest D 48%,
TUE 45 alt names
- high tech:
InHolland one of the two site not secured,
NOVI no name on certificate
Fontys Venlo: own brewn, one expired, one no name on cert, rating too low
A
B
C
D
E
F
= =
www.-
fontysvenlo fontysvenlo.nl /85.25.129.196 F 51% U
www.-
fontysven-
fontysvenlo lo.org /
85.214.143.122 F 51% U
intra.hva
intra.hva.nl /
145.92.231.174 A 85% T
webmail.h- webmail.h-
va.nl /
va
145.92.230.51
=
=
N
55% 40% 60% N
-
-
-
-
1 26-08-10 Plesk
- -
?
=
ses
resusion m
stric ption
t tran
sport
inse
cure
ren
eg.
PCI
FIPS
read
y
#cyp
hers
cyph
er ra
ng e
#wea
k cyp
hs
#ins
ec cy
Ephe phs
mera
l DH
-
cert typ
rev e
methocation SSL od
3.0
SSL 2
.0+
SSL 2.0
serv
nam er host e
cert CA
CN
certif on icate
Labs
ratin
g
av. r
ating
CA t
ruste
d
proto
col
key e
xcha
nge
ciph
ers
M ITM
?
www.fontys.nl /145.85.2.205
- =
#Alt nam
es
cert valid
unti
l
fontys
www
site
Org
iden ani-sati
tifier on assessments nearby (2011, Jan 26th)
=
= -
=
=
=
=
= -
Y
alpha526.ser
Y ver4you.de
=
N
N
N
N
20 40-256
9
0 512
1 Y
Y
fontysven-
Y lo.org
Y
N
Y
N
N
24 40-256
9
0 512
N Y
-
-
-
-
www.-
fontysven-
55% 40% 60% N
lo.org
1 16-11-12 CAcert
85% 80% 90% N intra.hva.nl
1 09-12-12 Terena DV
2 Y
Y
N intra.hva.nl
Y
N
N
Y
N
4128-256
0
0?
4 0-168
1
0?
?
B 69% T
85% 80% 50% N
webmail.h-
va.nl
1 28-11-11 Equifax DV
1 Y
Y
webmail.h-
N va.nl
Y
N
N
N
N
www6.volk
www6.volksun
suniver-
iversiteit.nl /
siteit
83.172.148.36 F 51% U
55% 40% 60% N
-
1 15-05-08 www15 ?
N Y
Y
www15.ante
Y nna.nl
Y
N
Y
N
N
21 40-256 10
0 512
internet security aware companies (17 sites)
high lights
⧫
A is high, F is low
4
A
B
C
D
E
F
Certificate Authorities (CA's)
CAcert (accred.), Pink Roccade (40 bits)
⧫
SSL Labs rating for internet sec
registries
2
10
Oct 2010
SSL Labs rating for internet sec
SIDN (2 different sites), RIPE (wild card)
⧫
others
A is high, F is low
3
A
B
C
D
E
F
2
Tunix, Gobal Sign, Qua Vadis,
EV SSL, etc.
12
Feb 2011
Perfect View Overheid (untrusted, no name, no revocation)
- mentioned
CA StartCom: provider, CA, highest score ever seen:
A 93%,
But still have insecure renegotiation
- SIDN:
two sites: WWW is weak but improved now, registry is OK
- NLNet Labs, CAcert:
got to F 91%, they clearly know ho
- either EV (30%) or not known, none with DV cert
70% support ephemeral DH (forwrad encryption)
- Tunix: only 52% rate, due to use insecure ciphers
red color: CAcert, Perfect Overheid, Quovadis Global, Nlnet Labs, 2Reclame, Nul77
Protocol issues with Quovadis Global, Nul77
gray color (C): Pink Roccade, Tunix
comments on SSL/TLS configurations
of Dutch web sites
⧫
none is FIPS 140-2, it ain't hard to do
⧫
end-user:
∘
unable to require acceptable security level,
∘
browser lock says only “maybe”
∘
CA coloring says only “maybe”
⧫
once HTTPS port, secure also the HTTP port
⧫
focus as well on other applications:
email, vpn, ssh, chat, etc.
⧫
accreditation of CA's and SSL/TLS configurations is far away
end-user trust is in danger, ... without a need for it
three basic things to do
the to-do
list of Neelie Kroes
1. DNSSEC: host identification
effectively secure DNS on the operational level
have data validated!
2. X.509 CERT: owner identification / validation
accredited CA's for end user and service provider
3. HTTP: SSL/TLS cipher suites policy
security policies defined, checked and maintained
configurations fixed, checked and maintained
validated -> certification
ASSESS all work done in a open and public way
after David Ross (DRC 2008)
“say what you do,
do what you say, evaluate and prove.”
tutorials, help, references and a lot more?
well, see the paper,
only ... 44 heavily loaded pages
FAQ
FAQ (1)
from the tweakers.net discussion Nov 2010
1. does it make sense to panic again?
2. EV cert is very expensive
FAQ
3. SSL is sufficient against snooping
4. mijning.nl confusion, they have an EV cert!
5. better to protect your money as your birth date info
6. why the hell, any hacker can go in easily
7. banks are not interested anyway
8. if banks anyway react is important
FAQ (2)
9.
certificate expired, what does that mean?
Is the site now insecure?
10. how can you compare the CA' s?
FAQ
11. certificate is the only thing needed for security.
12. can a CA from the US validate an entity in the EU?
13. what is the purpose of a certificate?
14. is a site with DV or EV certificate more secure?
15. should we lower security to any dummy level?
He, you make it impossible for my mam to use her bank account
16. he, you forgot to assess the Rabobank!

Slides with notes - front page fontysvenlo.org

Transcription

Similar documents

Project SweSSL

Amendments to L. E. Kastner`s Edition of Drummond`s Poems

8 Transport Layer Security (SSL/TLS)

SSL Eye Exam, One Million Websites, Banned

House Clearance – Furniture, Accessories and

Cairdin A6 postcard:Layout 1

Executive Speaker Series Luncheon

Northern Indiana Commuter Transportation District