Web Security

SSL

Dr. K. Kulothungan, Assistant Professor(Sr. Gr)

Outline
Web Security Considerations
Secure Socket Layer (SSL) and Transport Layer
Security (TLS)
Secure Electronic Transaction (SET)
Attacks in SSL

Why is the Internet insecure?

Host security

Client
Server (multi-user)

Transmission security
Passive sniffing
Active spoofing and
masquerading
Denial of service

Active content
Java, Javascript, ActiveX, DCOM

C
Eavesdropping
A

Denialofservice

B
C

A
C
B
Interception

C
Replay/fabrication
A

B
C

E-Commerce Security
Authorization, Access Control:
protect intranet from hordes: Firewalls

Confidentiality, Data Integrity:

protect contents against snoopers: Encryption

Authentication:
both parties prove identity before starting transaction:
Digital certificates

Non-repudiation:
proof that the document originated by you & you only:
Digital signature

Certification authority

Web Security Considerations

The WEB is very visible.

Complex software hide many security flaws.
Web servers are easy to configure and manage.
Users are not aware of the risks.

Henric Johnson

Major security issues

Prevent unauthorized users from accessing
sensitive data
Authentication: identifying users to determine if they
are one of the authorized ones
Access control: identifying which resources need
protection and who should have access to them

Prevent attackers from stealing data from

network during transmission
Encryption (usually by Secure Sockets Layer)

Web Application Security

Authentication
Collect user ID information from end users (logging
in)
usually by means of browser dialog / interface
user ID information normally refers to username and
password

Transport collected user ID information to the web

server
unsecurely (HTTP) or securely (HTTPS = HTTP over SSL)

Web Application Security

Authentication
Verify ID and passwd with backend Realms
(security database)
Realms maintain username, password, roles, etc., and can
be organized by means of LDAP, RDBMS, Flat-file, etc.
Validation: the web server checks if the collected user ID &
passwd match with these in the realms.

Keep track of previously authenticated users for

further HTTP operations

What is Secure Sockets Layer (SSL)?

A protocol developed in 1996 by Netscape for
securely transmitting private web documents over
the Internet.
It employs private and public key to encrypt data
thats transmitted over the SSL connection.
By convention, URLs that require SSL connection
start with https: (port 443) instead of http: (port 80).

Web Application Security

10

Why use SSL?

SSL is necessary if
There is a login or sign in (to protect user name
and passwd)
It transmits sensitive data online, such as credit
card information, Banking ID # etc.
You need to comply with privacy and security
requirements

Web Application Security

Source: www.verisign.com/ssl/ssl-information-center/how-ssl-security-works/index.html

11

Use of an SSL Certificate

To enable secured SSL connections, the server needs an
SSL certificate signed by a Certificate Authority (CA).
CA verifies the ID of the certificate owner (e.g., www.hsbc.com.hk)
when an SSL certificate is issued.

Each SSL Certificate contains unique and authenticated

information about the certificate owner, such as ID (in
X.500 format), location, public key, and the signature of
the CA.
It confirms that you are who you say you are in the Internet.

An SSL certificate enables encryption of sensitive

information during online transactions by means of using
hybrid cryptosystem.
Web Application Security

12

A Sample Certificate
This is a certificate issued by Ace CA:
Data
Version: v1 (0x0)
Serial Number: 1 (0x1)
Signature Algorithm: PKCS #1 MD5 With RSA Encryption
Issuer: OU=Ace Certificate Authority, O=Ace Ltd, C=US
Validity: Not Before: Fri Nov 15 00:24:11 1996
Not After: Sat Nov 15 00:24:11 1997
Subject: CN=Jane Doe, O=Ace Industry, C=US
Subject Public Key Info:
Algorithm: PKCS #1 RSA Encryption
Public Key:
00:d0:e5:60:7c:82:19:14:cf:38: F7:5b:f7:35:4e:14:41:2b:ec:24:
33:73:be:06:aa:3d:8b:dc:0d:06: 35:10:92:25:da:8c:c3:ba:b3:d7:
lf:1d:5a:50:6f:9a:86:53:15:f2: 53:63:54:40:88:a2:3f:53:11:ec: 68:fa:e1:f2:57
Public Exponent: 65537 (0x10001)
Signature
Algorithm: PKCS #1 MD5 With RSA Encryption
Signature:
12:f6:55:19:3a:76:d4:56:87:a6: 39:65:f2:66:f7:06:f8:10:de:cd:
1f:2d:89:33:90:3d:a7:e3:ec:27: ac:e1:c0:29:c4:5a:69:17:51:dc:
1e:0c:c6:5f:eb:dc:53:55:77:01: 83:8f:4a:ab:41:46:02:d7:c8:9a: fe:7a:91:5c

In Real World

In Real World

In Real World

In Real World

How SSL Works?

Good video tute at http://www.viddler.com/explore/sdennis/videos/5/

SSL handshake

Browser connects to SSL port 443 on the web server, and Hello msg
exchange btn browser & server on key-exchange, encrypt alg, etc

Web server sends back its SSL certificate. Web browser decides if it
wants to trust the web servers SSL certificate

Web Browser

Web browser and web server both calculate a session key by agreed
key-generation method
Web browser and web server negotiate an encryption cipher

Web Server

Web browser and web server exchange information encrypted by the

session key and the agreed encryption algorithm

More details at https://ssl.trustwave.com/support/support-how-ssl-works.php

18

CA Root Certificate

Web browser needs the root certificate of the CA that issued the
SSL certificate to the web-server to verify if the web server is
trustable.
If the browser does not have/trust the CA root certificate, most web
browsers will warn you

Web Application Security

19

Steps to Enable SSL in Apache Tomcat

1.

Obtain an SSL certificate for Apache Tomcat from a CA.

https://knowledge.verisign.com/support/ssl-certificatessupport/index?page=content&id=AR227

2.

Install CAs root certificate and Apache Tomcats SSL certificate to

Apache Tomcats keystore.
https://knowledge.verisign.com/support/ssl-certificatessupport/index?page=content&id=AR234

3.

Set up SSL parameters (port #, count, timeout, etc) by adding

<Connector scheme="https" secure="true">...</Connector>
XML block in conf/server.xml.
https://knowledge.verisign.com/support/ssl-certificatessupport/index?page=content&id=SO5306
Web Application Security

20

What is SSL/TLS?
Transport Layer Security protocol, version 1.0
De facto standard for Internet security
The primary goal of the TLS protocol is to provide privacy and
data integrity between two communicating applications
In practice, used to protect information transmitted between
browsers and Web servers

Based on Secure Sockets Layers protocol, ver 3.0

Same protocol design, different algorithms

Deployed in nearly every Web browser

SSL / TLS in the Real World

Application-Level Protection
applicati
on
presentati
on
sessio
n
transpo
rt
networ
k
data
link
physic
al

email, Web,
NFS

RP
C
TC
P
IP
802.1
1

Protects against application-level

threats (e.g., server
impersonation), NOT against IPlevel threats (spoofing, SYN flood,
DDoS by data flood)

History of the Protocol

SSL 1.0
Internal Netscape design, early 1994?
Lost in the mists of time

SSL 2.0
Published by Netscape, November 1994
Several weaknesses

SSL 3.0
Designed by Netscape and Paul Kocher, November 1996

TLS 1.0
Internet standard based on SSL 3.0, January 1999
Not interoperable with SSL 3.0
TLS uses HMAC instead of MAC; can run on any port

Request for Comments

Network protocols are usually disseminated in
the form of an RFC
TLS version 1.0 is described in RFC 2246
Intended to be a self-contained definition of the
protocol
Describes the protocol in sufficient detail for readers
who will be implementing it and those who will be
doing protocol analysis
Mixture of informal prose and pseudo-code

TLS Basics
TLS consists of two protocols
Familiar pattern for key exchange protocols

Handshake protocol
Use public-key cryptography to establish a shared
secret key between the client and the server

Record protocol
Use the secret key established in the handshake
protocol to protect communication between the
client and the server

We will focus on the handshake protocol

SSL Protocol Architecture

SSL
Handshake
Protocol

SSL
Change
Cipher
Spec
Protocol

SSL Alert
HTTP, other
Protocol
apps

SSL Record
Protocol
TCP

SSL/TLS Handshake Protocol

Two parties: client and server
Negotiate version of the protocol and the set of
cryptographic algorithms to be used
Interoperability between different implementations of
the protocol

Authenticate server and client (optional)

Use digital certificates to learn each others public
keys and verify each others identity

Use public keys to establish a shared secret

SSL Handshake
Client hello
Server hello
Present Server Certificate
*Request Client Certificate
Server Key Exchange

Client

Client Finish
*Present Client Certificate
Client Key Exchange
*Certificate Verify
Change Cipher Spec
Server Finish
Change Cipher Spec

Application Data

Server

Handshake Protocol Structure

ClientHello
ServerHello,
[Certificate],
[ServerKeyExchange],
[CertificateRequest],
ServerHelloDone

[Certificate],
ClientKeyExchange,
[CertificateVerify]
switch to negotiated cipher
Finished

Record of all sent and

received handshake
messages

switch to negotiated cipher

Finished

ClientHello
ClientHello

Client announces (in plaintext):

Protocol version he is running
Cryptographic algorithms he
supports

ClientHello (RFC)
Highest version of the
protocol supported by the
client

struct {
ProtocolVersion client_version;
Session id (if the client
Random random;
wants to resume an old
session)
SessionID session_id;
Set of cryptographic
algorithms supported by the
RSA or DiffieCipherSuite cipher_suites; client (e.g.,
Hellman)
CompressionMethod
compression_methods;
} ClientHello

ServerHello
Versionc, suitec, Nc

ServerHello

Server responds (in plaintext) with:

Highest protocol version
supported by
both client and server
Strongest cryptographic suite
selected
from those offered by the client

ServerKeyExchange
Versionc, suitec, Nc

Versions, suites, Ns,

ServerKeyExchange

Server sends his public-key

certificate
containing either his RSA, or
his Diffie-Hellman public key
(depending on chosen crypto suite)

ClientKeyExchange
Versionc, suitec, Nc

Versions, suites, Ns,

sigca(S,Ks),
ServerHelloDone

ClientKeyExchange

Client generates some secret key

material
and sends it to the server encrypted
with
the servers public key (if using RSA)

Core SSL 3.0 Handshake

Versionc=3.0, suitec, Nc
Versions=3.0, suites, Ns,
sigca(S,Ks),
ServerHelloDone

{Secretc}Ks
If the protocol is correct, C and S share
some secret key material (secretc) at this point
switch to key derived
from secretc, Nc, Ns

switch to key derived

from secretc, Nc, Ns

Core SSL 3.0 Handshake

(Contd)

The book shows the above protocol which is the same as the protocol
in the previous slide. Find out the correspondence between the
different notations that denote the same thing in these two protocols.

Version Rollback Attack

Versionc=2.0, suitec, Nc

Server is fooled into thinking

he is communicating with a
client who supports only SSL
2.0

Versions=2.0, suites, Ns,

sigca(S,Ks),
ServerHelloDone

{Secretc}Ks

C and S end up communicating using SSL 2.0

(weaker earlier version of the protocol that
does not include Finished messages)

SSL 2.0 Weaknesses (Fixed in 3.0)

Cipher suite preferences are not authenticated
Cipher suite rollback attack is possible

Truncation attack
Weak MAC construction
MAC hash uses only 40 bits in export mode
No support for certificate chains or non-RSA algorithms,
no handshake while session is open

Chosen-Protocol Attacks
Why do people release new versions of security
protocols? Because the old version got broken!
New version must be backward-compatible
Not everybody upgrades right away

Attacker can fool someone into using the old, broken

version and exploit known vulnerability
Similar: fool victim into using weak crypto algorithms

Defense is hard: must authenticate version early

Many protocols had version rollback attacks
SSL, SSH, GSM (cell phones)

Version Check in SSL 3.0

Versionc=3.0, suitec, Nc

Versions=3.0, suites, Ns,

sigca(S,Ks),

Embed version
number into
secret

{Versionc,Secretc}Ks

ServerHelloDone
Check that received version is
equal to the version in ClientHello

If the protocol is correct, C and S share

some secret key material secretc at this point

switch to key derived

from secretc, Nc, Ns

switch to key derived

from secretc, Nc, Ns

SSL/TLS Record Protection

Use symmetric keys

established in handshake proto

SSL Handshake Protocol Additional Features

SSL Handshake Protocol supports session
resumption and ciphersuite re-negotiation
Allows authentication and shared secrets to be reused
across multiple connections.
Eg, next webpage from same website.

Allows re-keying of current connection using fresh

nonces.
Allows change of ciphersuite during session.
ClientHello quotes old SessionID.
Both sides contribute new nonces, update secretc.
All protected by existing Record Protocol.

Session resumption
Public key operation is avoided

Other SSL Protocols

Alert protocol.
Management of SSL session, error messages.
Fatal errors and warnings.

Change cipher spec protocol.

Not part of SSL Handshake Protocol.
Used to indicate that entity is changing to recently agreed
ciphersuite.

Both protocols run over Record Protocol (so peers of

Handshake Protocol).

SSL/TLS Applications
Secure e-commerce using SSL/TLS.
Client authentication not needed until client decides to buy
something.
SSL provides secure channel for sending credit card
information.
Client authenticated using credit card information, merchant
bears (most of) risk.
Wildly successful (amazon.com, on-line supermarkets,)
Some famous disasters (boo.com, webvan), nothing to do with
security though.

SSL/TLS Applications
Secure e-commerce: some issues.
No guarantees about what happens to client data (including
credit card details) after session: may be stored on insecure
server.
Does client understand meaning of certificate expiry and
other security warnings?
Does client software actually check complete certificate
chain?
Does the name in certificate match the URL of e-commerce
site? Does the user check this?
Is the site the one the client thinks it is?
Is the client software proposing appropriate ciphersuites?

SSL/TLS Applications
Secure electronic banking.
Client authentication may be enabled using client
certificates.
Issues of registration, secure storage of private keys,
revocation and re-issue.

Otherwise, SSL provides secure channel for sending

username, password, mothers maiden name,
What else does client use same password for?

Does client understand meaning of certificate expiry and

other security warnings?
Is client software proposing appropriate ciphersuites?
Enforce from server.

Some SSL/TLS Security Flaws

(Historical) flaws in random number generation for SSL
Low quality RNG leads to predictable session keys.
Goldberg and Wagner, Dr. Dobbs Journal, Jan. 1996.

Flaws in error reporting.

(differing response times by server in event of padding failure and
MAC failure) + (analysis of padding method for CBC-mode) =
recovery of SSL plaintext.
Canvel, Hiltgen, Vaudenay and Vuagnoux, Crypto2003.

Timing attacks.
analysis of OpenSSL server response times allows attacker in
same LAN segment to derive servers private key!
.

Comparing IPsec and SSL/TLS

Both have initial (authenticated) key
establishment then key derivation.
IKE in IPsec
Handshake Protocol in SSL/TLS (can be
unauthenticated!)

Both protect ciphersuite negotiation.

Both use keys established to build a secure
channel.

Comparing IPsec and SSL/TLS

Operate at different network layers.
This brings pros and cons for each protocol suite.
Recall `Where shall we put security? discussion.
Naturally support different application types, can all be used to
build VPNs.

Both practical, but not simple.

Complexity leads to vulnerabilities.
Complexity makes configuration and management harder.

Comparing IPsec and SSL/TLS

Complexity can create computational bottlenecks.
Complexity necessary to give both flexibility and security.

Security of both undermined by:

Implementation weaknesses.
Weak server platform security.
Worms, malicious code, rootkits,

Weak user platform security.

Keystroke loggers, malware,

Comparing IPsec and SSL/TLS

Limited deployment of certificates and
infrastructure to support them.
Especially client certificates.

Lack of user awareness and education.

Users click-through on certificate warnings.
Users fail to check URLs.
Users send sensitive account details to bogus websites
(phishing) in response to official-looking e-mail.

SSL/TLS
Applications

Commerce

Commerce: Exchange of Goods / Services

Contracting parties: Buyer and Seller
Fundamental principles: Trust and Security
Intermediaries:
Direct (Distributors, Retailers)
Indirect (Banks, Regulators)

Money is a medium to facilitate transactions

Attributes of money:
Acceptability, Portability, Divisibility
Security, Anonymity
Durability, Interoperability

E-Commerce
Automation of commercial transactions using
computer and communication technologies
Facilitated by Internet and WWW
Business-to-Business: EDI
Business-to-Consumer: WWW retailing
Some features:
Easy, global access, 24 hour availability
Customized products and services
Back Office integration
Additional revenue stream

E-Commerce Steps
Attract prospects to your site
Positive online experience
Value over traditional retail

Convert prospect to customer

Provide customized services

Online ordering, billing and payment

Keep them coming back

Online customer service

Offer more products and conveniences

Maximize revenue per sale

E-Commerce Participants

E-Commerce Problems
Snoope
r
Unknown
customer
Unreliable
Merchant

E-Commerce risks
Customer's risks

Stolen credentials or password

Dishonest merchant
Disputes over transaction
Inappropriate use of transaction details

Merchants risk

Forged or copied instruments

Disputed charges
Insufficient funds in customers account
Unauthorized redistribution of purchased items

Main issue: Secure payment scheme

Electronic payments: Issues

Secure transfer across internet

High reliability: no single failure point
Atomic transactions
Anonymity of buyer
Economic and computational efficiency: allow
micropayments
Flexiblility: across different methods
Scalability in number of servers and users

E-Payments: Secure transfer

SSL: Secure socket layer
below application layer

S-HTTP: Secure HTTP:

On top of http

S-HTTP: Secure HTTP

Application level security (HTTP specific)
"Content-Privacy-Domain" header:
Allows use of digital signatures &/ encryption
Various encryption options

Server-Browser negotiate
Property: cryptographic scheme to be used
Value: specific algorithm to be used
Direction: One way/Two way security

Secure end to end protocols

E-Payments: Atomicity
Money atomicity: no creation/destruction of money
when transferred
Goods atomicity: no payment w/o goods and
viceversa.
Eg: pay on delivery of parcel

Certified delivery: the goods delivered is what was

promised:
Open the parcel in front of a trusted 3rd party

Anonymity of purchaser

Payment system types

Credit card-based methods
Credit card over SSL
First Virtual
SET

Electronic Cheques
NetCheque

Anonymous payments
Digicash
CAFE

Micropayments
SmartCards

Encrypted credit card payment

Set secure communication channel between buyer and
seller
Send credit card number to merchant encrypted using
merchants public key
Problems: merchant fraud, no customer signature
Ensures money but no goods atomicity
Not suitable for microtransactions

First virtual

Customer assigned virtual PIN by phone

Customer uses PIN to make purchases
Merchant contacts First virtual
First virtual send email to customer
If customer confirms, payment made to merchant
Not goods atomic since customer can refuse to pay
Not suitable for small transactions
Flood customers mailbox, delay merchant

Cybercash
Customer opens account with cybercash, gives
credit card number and gets a PIN
Special software on customer side sends PIN,
signature, transaction amount to merchant
Merchant forwards to cybercash server that
completes credit card transaction
Pros: credit card # not shown to server, fast
Cons: not for microtransactions

SET:Secure Electronic Transactions

Merge of STT, SEPP, iKP (IBM (iKP). Mastercard (SEPP). Microsoft and Visa (STT))
Secure credit card based protocol
Common structure:
Customer digitally signs a purchase along with price and
encrypts in banks public key
Merchant submits a sales request with price to bank.
Bank compares purchase and sales request. If price match,
bank authorizes sales

Avoids merchant fraud, ensures money but no goods

atomicity

SET Participants

Henric Johnson

72

Dual Signature
DS E KRc [ H ( H ( PI ) || H(OI))]

73

Payment processing

Cardholder sends Purchase Request

74

Payment processing

Merchant Verifies Customer Purchase Request

75

Payment processing
Payment Authorization:
Authorization Request
Authorization Response

Payment Capture:
Capture Request
Capture Response

76

Electronic Cheques
Leverages the check payments system, a core
competency of the banking industry.
Fits within current business practices
Works like a paper check does but in pure
electronic form, with fewer manual steps.
Can be used by all bank customers who have
checking accounts
Different from Electronic fund transfers

How does echeck work?

Exactly same way as paper
Check writer "writes" the echeck using one of
many types of electronic devices
Gives" the echeck to the payee electronically.
Payee "deposits" echeck, receives credit,
Payee's bank "clears" the echeck to the
paying bank.
Paying bank validates the echeck and
"charges" the check writer's account for the
check.

Anonymous payments

1.Withdrawmoney:
cyrpographicallyencoded
tokens

customer

5.Deposittokenatbank.
Ifdoublespentreveal
identityandnotifypolice

3.Sendtokenafteradding
merchantsidentity

4.Checkvalidityandsendgoods
2.Transformsomerchantcancheck
validitybutidentityhidden

merchant

Problems with the protocol

Not money atomic: if crash after 3, money lost
if money actually sent to merchant: returning to bank
will alert police
if money not sent: not sending will lead to loss

High cost of cryptographic transformations: not

suitable for micropayments
Examples: Digicash

Micropayments on hyperlinks

HTML extended to have pricing details with each

link: displayed when user around the link
On clicking, browser talks to E-Wallet that
initiates payment to webserver of the source site
Payment for content providers
Attempt to reduce overhead per transaction

Micropayments: NetBill
Customer & merchant have account with NetBill server
Protocol:
Customer request quote from merchant, gets quote and
accepts
Merchant sends goods encrypted by key K
Customer prepares & signs Electronic Purchase Order having
<price, crypto-checksum of goods>
Merchant countersigns EPO, signs K and sends both to
NetBill server
NetBill verifies signatures and transfers funds, stores K and
crypto-checksum and
NetBill sends receipt to merchant and K to customer

Recent micropayment systems

Company
Compaq
IBM
France
Telecom

Payment
system
Millicent

Unique
code
mcent

IBM payment
system
Micrommerce

mpay
microm

Smartcards
8-bit micro, < 5MHz, < 2k RAM, 20k ROM
Download electronic money on a card: wallet on a
card
Efficient, secure, paperless, intuitive and speedy
Real and virtual stores accept them
Less susceptible to net attacks since disconnected
Has other uses spanning many industries, from
banking to health care

Mondex
Smart card based sales and card to card transfers
Money is secured through a password and
transactions are logged on the card
Other operation and features similar to traditional
debit cards
Card signs transaction: so no anonymity
Need card reader everywhere
Available only in prototypes

Comparison of SSL V2.0 and V3.0

SSL 2.0 is vulnerable to man-in-the-middle attack. The hello
message can be modified to use 40 bits encryption.

SSL 3.0 defends against this attack by having the last handshake
message include a hash of all the previous handshake message

SSL 2.0 uses a weak MAC construction

In SSL 3.0, the Message Authentication Hash uses a full 128 bits of
key material for Export cipher, while SSL 2.0 uses only 40 bits

86

Comparison of SSL V2.0 and V3.0

SSL 2.0 only allows a handshake at the beginning of
the connection. In 3.0, the client can initiate a
handshake routine any time
SSL 3.0 allows server and client to send chains of
certificate
SSL 3.0 has a generalized key exchange protocol. It
allows Diffie-Hellman and Fortezza key exchange
SSL 3.0 allows for record compression and
decompression

87

Problem Free?
Side channel attack discovered by Swiss Federal Institute of
Technology in Lausanne

http://www.newsfactor.com/perl/story/20843.html

Information leak in encrypted connections. Vulnerable openssl

versions do not perform a MAC computation if an incorrect block
cipher padding is used.
An active attacker who can insert data into an existing encrypted
connection is then able to measure time differences between the
error messages the server sends.
This information can make it easier to launch cryptographic attacks
that rely on distinguishing between padding and MAC verification
errors, possibly leading to extraction of the original plaintext.

88

SSL Attacks
SSLstrip, Slowloris & Scary

SSL Attacks
sslstrip Steals passwords from mixed-mode Web
login pages
Slowloris Denial of Service Stops Apache Web
servers
Scary SSL Attacks--ways to completely fool
browsers

sslstrip

The 15 Most Popular Web 2.0 Sites

1. YouTube
HTTPS
2. Wikipedia HTTP
3. Craigslist
HTTPS
4. PhotobucketHTTP
5. Flickr HTTPS
6. WordPress MIXED
7. Twitter MIXED
8. IMDB HTTPS

The 15 Most Popular Web 2.0 Sites

9. Digg HTTP
10. eHow
HTTPS
11. TypePad HTTPS
12. topix HTTP
13. LiveJournal
Obfuscated HTTP
14. deviantART
MIXED
15. Technorati HTTPS
From http://www.ebizmba.com/articles/user-generated-content

Password Stealing
Medium
ssltrip

Hard
Spoofing Certificates

Easy
Wall of Sheep

Mixed Mode
HTTP Page with an HTTPS Logon Button

sslstrip Proxy Changes HTTPS to

HTTP

To
Internet

HTTPS

HTTP
Target
Using
Facebook

Attacker:
sslstrip
Proxy
in the
Middle

Ways to Get in the Middle

Physical Insertion in a Wired

Network

To
Internet

Attacker

Target

Configuring Proxy Server in the

Browser

ARP Poisoning

Redirects Traffic at Layer 2

Sends a lot of false ARP packets on the LAN
Can be easily detected
DeCaffienateID by IronGeek
http://k78.sl.pt

ARP Request and Reply

Client wants to find Gateway
ARP Request: Who has 192.168.2.1?
ARP Reply:
MAC: 00-30-bd-02-ed-7b has 192.168.2.1

ARP Request
ARP Reply
Client

Gateway

Facebook.com

ARP Poisoning

Attacker
ARP Replies: I
am the
Gateway

Forwarded &
Altered Traffic
Traffic to
Facebook

Client

Gateway

Facebook.com

Demonstration

slowloris

HTTP GET

Send Incomplete HTTP Requests

Apache has a queue of approx. 256 requests
Each one waits approx. 400 seconds by
default for the request to complete
So less than one packet per second is enough
to occupy them all
Low-bandwidth DoS--no collateral damage!

OSI Model
OSI Model

DoS Attack

7 Application

Slowloris Incomplete HTTP Requests

6 Presentation
5 Session
4 Transport

SYN Flood Incomplete TCP Handshakes

3 Network
2 Data Link
1 Physical

Cut a cable

DDoS Attacks in the Wake of French

Anti-terror Demonstrations

DDoS Attacks in the Wake of French Anti-terror Demonstrations

On January 15th, Frances chief information systems defense
official, Adm. Arnaud Coustilliere, announced a sharp rise in online
attacks against French web sites:
Calling it an unprecedented surge, Adm. Arnaud Coustilliere, head
of cyberdefense for the French military, said about 19,000 French
websites had faced cyberattacks in recent days, [1].
As weve done in the recent past for North Korea [2], Hong-Kong [3],
and Israel [4], we can leverage Arbors ATLAS initiative to observe
how real world conflict []

North Korea Goes Offline

North Korea Goes Offline
It was reported earlier today that North Korea was having Internet
connectivity issues.
Given recent events involving Sony Pictures Entertainment (SPE),
these reports are of particular interest. The first question when
you see this type of report is whether its purely a connectivity
issue or whether an attack is behind it. While visibility into North
Korean Internet is quite difficult, we are able to see quite a few
attacks over the last few days.

Demonstration

Scary SSL Attacks

Man in the Middle

To
Internet
HTTPS

HTTPS
Target
Using
https://gmail.com

Attacker:
Cain: Fake
SSL
Certificate

Warning Message

Certificate Errors
The message indicates that the Certificate
Authority did not validate the certificate
BUT a lot of innocent problems cause those
messages
Incorrect date settings
Name changes as companies are acquired

Most Users Ignore Certificate Errors

Link SSL-1 on my CNIT 125 page

Fake SSL With No Warning

Impersonate a real Certificate Authority
Use a Certificate Authority in an untrustworthy
nation
Trick browser maker into adding a fraudulent CA to
the trusted list
Use a zero byte to change the effective domain
name
Wildcard certificate

Impersonating Verisign

Researchers created a rogue Certificate

Authority certificate, by finding MD5 collisions
Using more than 200 PlayStation 3 game consoles

Link SSL-2

Countermeasures
Verisign announced its intent to replace MD5 hashes
(presumably with SHA hashes), in certificates issued
after January, 2009
Earlier, vulnerable certificates would be replaced only if
the customer requested it
Link SSL-4

FIPS 140-1 (from 2001) did not recognize MD5 as

suitable for government work
Links SSL-5, SSL-6, SSL-7

CA in an Untrustworthy Nation

Link SSL-8

Unknown Trusted CAs

An unknown entity was apparently trusted for

more than a decade by Mozilla
Link SSL-9

Zero Byte Terminates Domain Name

Just buy a certificate for Paypal.com\0.evil.com

Browser will see that as matching paypal.com

Link SSL-10

Thank You
Kulo.tn@auist.net