PGP

Subject Name: Computer Networks

Unit No: 06 Unit Name: Application Layer

Faculty Name : Mrs. Puja Padiya

Index

Lecture 1 – DNS

Lecture 2 – HTTP

Lecture 3 – Email, SMTP

Lecture 4 – Telnet

Lecture 5 – FTP

Lecture 6 – Security SSH PGP

2

6

8

2

2

4

5

Unit No: 6 Unit name: Application Layer

Lecture No: 1

DNS

OBJECTIVES:



To describe the purpose of DNS.

 To define the concept of domains and domain name space.



To describe the distribution of name spaces and define zones.



To discuss the use of DNS in the Internet and describe three categories of domains: generic, country, and reverse.



To discuss name-address resolution and show the two resolution methods: recursive and iterative.



To show the format of DNS message and how they can be compressed.



To discuss DDNS and DNSSEC..

4 TCP/IP Protocol Suite

Chapter

Outline

19.1 Need for DNS

19.2 Name Spaces

19.3 DNS in the Internet

19.4 Resolution

19. 5 DNS Messages

19. 6 Types of Records

19. 7 Compression

19. 8 Encapsulation

19. 9 Registrars

19. 10 DDNS

TCP/IP Protocol Suite

19. 11 Security of DNS

5

19-1 NEED FOR DNS

To identify an entity, TCP/IP protocols use the IP address, which uniquely identifies the connection of a host to the Internet. However, people prefer to use names instead of numeric addresses. Therefore, we need a system that can map a name to an address or an address to a name.


Figure 19.1

Purpose of DNS

User

1

Host name

2

Host name

IP address

5

6

IP address

Transport layer

3 Query


Response 4

19-2 NAME SPACE

To be unambiguous, the names assigned to machines must be carefully selected from a name space with complete control over the binding between the names and IP addresses. In other words, the names must be unique because the addresses are unique. A name space that maps each address to a unique name can be organized in two ways: flat or hierarchical.


Topics Discussed in the Section



Flat Name Space



Hierarchical Name Space



Domain Name Space



Domain



Distribution of Name Space


Figure 19.2

Domain name space


Figure 19.3

Domain names and labels


Figure 19.4

FQDN and PQDN


Figure 19.5

Domains


Figure 19.6

Hierarchy of name servers


Figure 19.7

Zones and domains


Note

A primary server loads all information from the disk file; the secondary server loads all information from the primary server.

When the secondary downloads information from the primary, it is called zone transfer.


19-3 DNS IN THE INTERNET

DNS is a protocol that can be used in different platforms. In the Internet, the domain name space

(tree) is divided into three different sections: generic domains, country domains, and the inverse domain

(see Figure 19.8).





Generic Domains



Country Domains



Inverse Domain



Registrar


Figure 19.8

DNS used in the Internet


Figure 19.9

Generic domains



Figure 19.10

Country domains


Figure 19.11

Inverse domain


19-4 RESOLUTION

Mapping a name to an address or an address to a name is called name-address resolution.





Resolver



Mapping Names to Addresses



Mapping Addresses to Names



Recursive Resolution



Iterative Resolution



Caching


Figure 19.12

Recursive resolution

1

10


2

9

3

8

7

4

6

5

Figure 19.13

Iterative resolution

6

5

1

2

3

4

7

8

10

9


19-5 DNS MESSAGES

DNS has two types of messages: query and response. Both types have the same format. The query message consists of a header and question records; the response message consists of a header, question records, answer records, authoritative records, and additional records (see

Figure 19.14).





Header


Figure 19.14

Query and response messages


Figure 19.15

Header format


19-8 ENCAPSULATION

DNS can use either UDP or TCP. In both cases the well-known port used by the server is port 53. UDP is used when the size of the response message is less than 512 bytes because most UDP packages have a 512-byte packet size limit. If the size of the response message is more than 512 bytes, a TCP connection is used. In that case, one of two scenarios can occur:


19-9 REGISTRARS

How are new domains added to DNS? This is done through a registrar, a commercial entity accredited by ICANN. A registrar first verifies that the requested domain name is unique and then enters it into the

DNS database. A fee is charged.


19-10 DDNS

When the DNS was designed, no one predicted that there would be so many address changes. In DNS, when there is a change, such as adding a new host, removing a host, or changing an IP address, the change must be made to the DNS master file. The

DNS master file must be updated dynamically. The

Dynamic Domain Name System (DDNS) therefore was devised to respond to this need.


19-11 SECURITY OF DNS

DNS is one of the most important systems in the

Internet infrastructure; it provides crucial services to the

Internet users. Applications such as Web access or email are heavily dependent on the proper operation of

DNS. DNS can be attacked in several

Ways.

To protect DNS, IETF has devised a technology named DNS Security (DNSSEC) that provides the message origin authentication and message integrity using a security service called digital signature (See

Chapter 29).



Lecture No: 2

HTTP

HyperText Transfer Protocol (HTTP)

• HTTP is the protocol that supports communication between web browsers and web servers.

• A “Web Server” is a HTTP server

• Most clients/servers today speak version 1.1, but 1.0 is also in use.

– RFC 1945 (HTTP 1.0)

– RFC 2616 (HTTP 1.1)

HTTP 37

From the RFC

• “HTTP is an application-level protocol with the lightness and speed necessary for distributed, hypermedia information systems.”

• Transport Independence

– The HTTP protocol generally takes place over a

TCP connection,

– but the protocol itself is not dependent on a specific transport layer.

HTTP 38

Request - Response

• HTTP has a simple structure:

– client sends a request

– server returns a reply.

• HTTP can support multiple request-reply exchanges over a single TCP connection.

• The “well known” TCP port for HTTP servers is port 80.

– Other ports can be used as well...

39

HTTP 1.0+ Request

• Lines of text (ASCII).

• Lines end with CRLF “\r\n”

• First line is called “Request-Line”

Request-Line

Headers

.

blank line

Content...

HTTP 40

Request Line

Method URI HTTP-Version\r\n

• The request line contains 3 tokens (words).

• space characters “ “ separate the tokens.

• Newline (\n) seems to work by itself

– but the protocol requires CRLF

HTTP 41

Request Method

• The Request Method can be:

GET

DELETE

HEAD

PUT

TRACE

POST

OPTIONS future expansion is supported

• GET, HEAD and POST are supported

HTTP everywhere (including Lab 2!).

42

Methods

• GET: retrieve information identified by the URI.

– Typically used to retrieve an HTML document

• HEAD: retrieve meta-information about the

URI.

– used to find out if a document has changed

• POST: send information to a URI and retrieve result.

HTTP

– used to submit a form

43

More Methods

• PUT: Store information in location named by URI.

• DELETE: remove entity identified by URI.

• TRACE: used to trace HTTP forwarding through proxies, tunnels, etc.

• OPTIONS: used to determine the capabilities of the server, or characteristics

44

URI: Universal Resource Identifier

• URIs defined in RFC 2396.

• Absolute URI:

– scheme://hostname[:port]/path

– http://www.cse.unr.edu:80/~mgunes/c pe401

• Relative URI:

– /path

– /blah/foo

No server mentioned

HTTP 45

URI Usage

• When dealing with a HTTP 1.1 server, only a

path is used (no scheme or hostname).

– HTTP 1.1 servers are required to be capable of handling an absolute URI, but there are still some out there that won’t…

• When dealing with a proxy HTTP server, an absolute URI is used.

– client has to tell the proxy where to get the document!

– more on proxy servers in a bit….

46

HTTP Version Number

“ HTTP/1.0

” or “ HTTP/1.1

”

• Starting with HTTP 1.0 the version number is part of every request.

– Client tells the server what version it can talk

(what options are supported, etc).

• HTTP 0.9 did not include a version number in a request line.

– If a server gets a request line with no HTTP version number, it assumes 0.9

HTTP

– HTTP 0.9 was used for many years.

47

The Header Lines

• Request Headers provide information to the server about the client

– what kind of client

– what kind of content will be accepted

– who is making the request

• Each header line contains

– an attribute name followed by a “:” followed by a space and the attribute value.

• There can be 0 headers (HTTP 1.0)

• HTTP 1.1 requires a Host: header

HTTP 48

Example HTTP Headers

Accept: text/html

Host: www.cse.unr.edu

From: mgunes@cse.unr.edu

User-Agent: Mozilla/4.0

Referer: http://www.unr.edu/

HTTP 49

End of the Headers

• Each header ends with a CRLF ( \r\n )

• The end of the header section is marked with a blank line.

– just CRLF

• For GET and HEAD requests, the end of the headers is the end of the request!

HTTP 50

POST

• A POST request includes some content (some

data) after the headers (after the blank line).

• There is no format for the data (just raw bytes).

• A POST request must include a Content-Length line in the headers:

Content-length: 267

HTTP 51

Example POST Request

POST /~mgunes/cpe401/grades.cgi HTTP/1.1

Accept: */*


User-Agent: SecretAgent V2.3

Content-Length: 35

Referer: http://www.unr.edu/ stuid=6660182722&item=test1&grade=99

HTTP 52

Example GET Request

GET /~mgunes/cpe401/lab1.htm HTTP/1.1

Accept: */*


User-Agent: Internet Explorer

From: mgunes@cse.unr.edu

Referer: http://www.unr.edu/

There is a blank line here!

HTTP 53

HTTP Response

• ASCII Status Line

• Headers Section

Status-Line

Headers

.

blank line

Content...

• Content can be anything (not just text)

– typically an HTML document or some kind of image.

HTTP 54

Response Status Line

HTTP-Version Status-Code Message

• Status Code is 3 digit number (for computers)

– 1xx Informational

– 2xx Success

– 3xx Redirection

– 4xx Client Error

– 5xx Server Error

• Message is text (for humans)

55

Example Status Lines

HTTP/1.0 200 OK

HTTP/1.0 301 Moved Permanently

HTTP/1.0 400 Bad Request

HTTP/1.0 500 Internal Server

Error

HTTP 56

Response Headers

• Provide the client with information about the returned entity (document).

– what kind of document

– how big the document is

– how the document is encoded

– when the document was last modified

• Response headers end with blank line

HTTP 57

Response Header Examples

Date: Wed, 30 Jan 2002 12:48:17

EST

Server: Apache/1.17

Content-Type: text/html

Content-Length: 1756

58

Content

• Content can be anything (sequence of raw bytes).

• Content-Length header is required for any response that includes content.

• Content-Type header also required.

HTTP 59

Single Request/Reply

• The client sends a complete request.

• The server sends back the entire reply.

• The server closes it’s socket.

• If the client needs another document it must open a new connection.

This was the default for HTTP 1.0

HTTP 60

Persistent Connections

• HTTP 1.1 supports persistent connections (this is the default).

• Multiple requests can be handled over a single

TCP connection.

• The Connection: header is used to exchange information about persistence

(HTTP/1.1)

• 1.0 Clients used a Keep-alive: header

HTTP 61

Try it with telnet

> telnet www.cse.unr.edu 80

GET / HTTP/1.0

HTTP/1.0 200 OK

Server: Apache

...

HTTP 62

Try it with telnet (persistent)

> telnet www.cse.unr.edu 80

GET / HTTP/1.1


HTTP/1.0 200 OK

Server: Apache

...

HTTP 63

HTTP Proxy Server

Browser Proxy

HTTP

Server

HTTP 64

Network Lab #2 HTTP Proxy

• You need to write a proxy server.

• Must be able to handle GET, HEAD and POST requests.

• Filtering: Your proxy will be given a list of domain names on the command line, you should refuse to forward requests to any server whose name is within a specified domain.

– send back status line: 403 Forbidden .

65

The code you need

• Proxy is both a client and a server

• Parsing the HTTP request is needed.

– You need to understand HTTP

• You will need to parse headers.

– need to look at Content-length, Connection, etc.

Lab #2 66

Testing

• Tell your browser to use a proxy

– Edit preferences/options.

• Interrupt a long transfer (press stop).

• Fill out a form (probably uses POST).

• Test it with a browser.

• Test it with telnet

• Write an abusive client and a rude server!

Lab #2 67

What is expected

• We should be able to surf through your proxy!

• Proxy should print some info about each request (print the request line).

• No memory leaks!

• Check every system call for errors!

– We should not be able to kill your proxy by

• sending a bad request.

• using a server that sends bad replies.

– No crashes, no matter what kind of nonsense we send your proxy.

Lab #2 68

HTTP V1.1 Details

• The RFC is 114 pages!

• we don’t expect you to read it all or to support every nitty-gritty detail.

• work on creating a working proxy (one you can use through a browser).

– performance is not a big deal (but it shouldn’t be horribly worse than without your proxy).

• Don’t worry about persistence, pipelining, chunking, etc.

– you need to turn off persistence if you don't want to handle it.

Lab #2 69

HTTP Headers

• You will need to look at the Content-Length header in a POST.

– you need to know how many bytes to read after the end of the headers.

• You will need to either look at

Connection ( Proxy-Connection ) headers or (at a minimum) to force

Connection: close as a request header.

Lab #2 70


Lecture No: 3

Email, SMTP

OBJECTIVES:



To explain the architecture of electronic mail using four scenarios.

 To explain the user agent (UA), services provided by it, and two types of user agents.

 To explain the mechanism of sending and receiving e-mails.



To introduce the role of a message transfer agent and Simple Mail



Transfer Protocol (SMTP) as the formal protocol that handles MTA.



To explain e-mail transfer phases.



To discuss two message access agents (MAAs): POP and IMAP.


OBJECTIVES (continued):



To discuss MIME as a set of software functions that transforms non-

ASCII data to ASCII data and vice versa.



To discuss the idea of Web-based e-mail.

 To explain the security of the e-mail system.


Chapter

Outline

23.1 Architecture

23.2 User Agent

23.3 Message Transfer Agent

23.4 Message Access Agent

23.5 MIME

23.6 Web-Based Mail


23.7 Electronic Mail Security

23-1 ARCHITECTURE

To explain the architecture of e-mail, we give four scenarios. We begin with the simplest situation and add complexity as we proceed. The fourth scenario is the most common in the exchange of e-mail.





First Scenario



Second Scenario



Third Scenario



Fourth Scenario


Figure 23.1

First scenario


1

2

Note

When the sender and the receiver of an email are on the same mail server, we need only two user agents.


Figure 23.2

Second scenario

1

2 3

4

5


Note

When the sender and the receiver of an email are on different mail servers, we need two UAs and a pair of MTAs (client and server).


Figure 23.3

Third scenario

1

2

4

3

5

6

7


Note

When the sender is connected to the mail server via a LAN or a WAN, we need two UAs and two pairs of MTAs

(client and server).


Figure 23.4

Fourth scenario

1

2

3

4

5

6

8

9


Note

When both sender and receiver are connected to the mail server via a LAN or a

WAN, we need two UAs, two pairs of MTAs

(client and server), and a pair of MAAs

(client and server). This is the most common situation today.


Figure 23.5

Push versus pull


23-2 USER AGENT

The first component of an electronic mail system is the user agent (UA). It provides service to the user to make the process of sending and receiving a message easier.





Services Provided by a User Agent



User Agent Types



Sending Mail



Receiving Mail



Addresses



Mailing List or Group List


Note

Some examples of command-driven user agents are mail, pine, and elm.


Note

Some examples of GUI-based user agents are Eudora, Outlook,

And Netscape.


Figure 23.6

Format of an email


Figure 23.7

E-mail address


23-3 MESSAGE TRANSFER AGENT

The actual mail transfer is done through message transfer agents (MTAs). To send mail, a system must have the client MTA, and to receive mail, a system must have a server MTA. The formal protocol that defines the MTA client and server in the Internet is called Simple Mail Transfer Protocol (SMTP). As we said before, two pairs of MTA client-server programs are used in the most common situation (fourth scenario). Figure 23.8 shows the range of the SMTP protocol in this scenario.





Commands and Responses



Mail Transfer Phases


Figure 23.8

SMTP range


Figure 23.9

Commands and responses




Figure 23.10

Connection establishment

2


220 service ready

HELO: deanza.edu

250 OK

1

3

Figure 23.11

Message transfer


Figure 23.12

Connection termination

1 QUIT

221 service closed


2

Example 23.1

Let us see how we can directly use SMTP to send an e-mail and simulate the commands and responses we described in this section. We use TELNET to log into port 25 (the well-known port for SMTP). We then use the commands directly to send an e-mail. In this example, forouzanb@adelphia.net is sending an e-mail to himself. The first few lines show TELNET trying to connect to the adelphia mail server.

After connection, we can type the SMTP commands and then receive the responses as shown below. We have shown the commands in black and the responses in color. Note that we have added for clarification some comment lines, designated by the “=” sign. These lines are not part of the e-mail procedure.


Example 19.1 Continued


23-4 MESSAGE ACCESS AGENT

The first and the second stages of mail delivery use

SMTP. However, SMTP is not involved in the third stage because SMTP is a push protocol; it pushes the message from the client to the server. In other words, the direction of the bulk data (messages) is from the client to the server. On the other hand, the third stage needs a pull protocol; the client must pull messages from the server. The direction of the bulk data are from the server to the client. The third stage uses a message access agent.


23-6 WEB-BASED MAIL

E-mail is such a common application that some websites today provide this service to anyone who accesses the site. Three common sites are Hotmail,

Yahoo, and Google. The idea is very simple. Let us go through two cases:





Case I



Case II


Figure 23.19

Web-based e-mail, case 1

1

2

3

4

HTTP transactions


Figure 23.20

Web-based e-mail, case 2

HTTP transactions

1 2 3

HTTP transactions


23-6 E-MAIL SECURITY

The protocol discussed in this chapter does not provide any security provisions per se. However, email exchanges can be secured using two application-layer securities designed in particular for e-mail systems. Two of these protocols, Pretty Good

Privacy (PGP) and Secure MIME (SMIME) are discussed in Chapter 30 after we have discussed the basic network security.



Lecture No: 4

Telnet

TELNET vs. telnet

• TELNET is a protocol that provides “a general, bi-directional, eight-bit byte oriented communications facility”.

• telnet is a program that supports the

TELNET protocol over TCP.

• Many application protocols are built upon the

TELNET protocol.

TELNET 110

The TELNET Protocol

 Reference: RFC 854

• TCP connection

• data and control over the same connection.

• Network Virtual Terminal

– intermediate representation of a generic terminal.

– provides a standard language for communication of terminal control functions.

TELNET 111

Network Virtual Terminal

NVT

TCP

TELNET

Server

Process

NVT

TCP

112

Negotiated Options

• All NVTs support a minimal set of capabilities.

– Some terminals have more capabilities than the minimal set.

• The set of options is not part of the TELNET protocol,

– so that new terminal features can be incorporated without changing the TELNET protocol.

• Two endpoints negotiate a set of mutually acceptable options

– Line mode vs. character mode

– echo modes

TELNET

– character set (EBCDIC vs. ASCII)

113

Control Functions

• TELNET includes support for a series of control functions commonly supported by servers.

• This provides a uniform mechanism for communication of (the supported) control functions.

TELNET 114

Control Functions

• Interrupt Process (IP)

– suspend/abort process.

• Abort Output (AO)

– send no more output to user’s terminal.

• Are You There (AYT)

– check to see if system is still running.

• Erase Character (EC)

– delete last character sent

• Erase Line (EL)

– delete all input in current line.

115

Command Structure

• All TELNET commands and data flow through the same TCP connection.

• Commands start with a special character called the Interpret as Command escape character

– The IAC code is 255.

– If a 255 is sent as data - it must be followed by another 255.

• If IAC is found and the next byte is IAC

– a single byte is presented to application/terminal

• If IAC is followed by any other code

– TELNET the TELNET layer interprets this as a command.

116

Playing with TELNET

• You can use the telnet program to play with the TELNET protocol.

• telnet is a generic TCP client.

– Sends whatever you type to the TCP socket.

– Prints whatever comes back through the TCP socket

– Useful for testing TCP servers (ASCII based protocols).

• Many Unix systems have these servers running

(by default):

– echo port 7 discard port 9 117

telnet hostname port

> telnet amele-2.cse.unr.edu 7

Trying 134.197.40.246...

Connected to amele-

2.cse.unr.edu

(134.197.40.246).

Escape character is '^]'.

Hi mehmet

Hi mehmet stop it stop it

^] telnet> quit

TELNET 118

telnet vs. TCP

• Not all TCP servers talk TELNET (most don't)

• You can use the telnet program to play with these servers, but the fancy commands won't do anything.

– type ^], then "help" for a list of fancy TELNET stuff you can do in telnet .

TELNET 119


Lecture No: 5

FTP

21-1 FTP

File Transfer Protocol (FTP) is the standard mechanism provided by TCP/IP for copying a file from one host to another. Although transferring files from one system to another seems simple and straightforward, some problems must be dealt with first. For example, two systems may use different file name conventions. Two systems may have different ways to represent text and data. Two systems may have different directory structures. All of these problems have been solved by FTP in a very simple and elegant approach.





Connections



Communication



Command Processing



File Transfer



Anonymous FTP



Security for FTP



The sftp Program


Note

FTP uses the services of TCP.

It needs two TCP connections. The wellknown port 21 is used for the control connection and the well-known port 20 for the data connection.


Figure 21.1

FTP


Figure 21.2

Opening the control connection


Figure 21.3

Creating the data connection


Figure 21.4

Using the control connection


Figure 21.5

Using the data connection


Figure 21.6

Command processing










Figure 21.7

File transfer


Example 21.1

Figure 21.8 shows an example of using FTP for retrieving a list of items in a directory.


Figure 21.8

Example 21.1

2

4

6

8

220 (Service ready)

USER forouzan

331 (User name OK. Password?)

PASS xxxxxx

230 (User login OK)

PORT 8888

150 (Data connection opens shortly)

LIST /usr/user/forouzan/reports

125 (Data connection OK)

1

3

5

7

9

DATA

TRANSFER

13

226 (Closing data connection)

QUIT

221 (Service closing)


12

14

List of files or directories 10

List of files or directories 11

Example 21.2

The following shows an actual FTP session that parallels

Example 21.1. The colored lines show the responses from the server control connection; the black lines show the commands sent by the client. The lines in white with black background show data transfer.


Example 21.3

Figure 21.9 shows an example of how an image (binary) file is stored.


Figure 21.9

Example 21.3

2

4

6

8

10

12

220 (Service ready)

USER forouzan

331 (User name OK. Password?)

PASS xxxxxx

230 (User login OK)

PORT 1267

150 (Data connection opens shortly)

TYPE EBCDIC

200 (OK)

STRU R

200 (OK)

STOR/usr/user/forouzan/reports/file1

250 (OK)

1

3

5

7

9

11

13

17

DATA

TRANSFER

226 (Closing data connection)

QUIT

221 (Service closing)

16

18


14

15

Records of file ..........

Records of file ..........

Example 21.4

We show an example of anonymous FTP. We assume that some public data are available at internic.net.



Lecture No: 6

Security SSH PGP

Outline

 Introduction

 Brief History

 What is Secure Shell ?

 Features of Secure Shell

 Security Mechanism of Secure Shell

 SSH1 vs. SSH2

 Conclusion

Introduction

Widely used utilities to login through a network in

Unix environment are telnet and rlogin

Problem - user's login name and password transmitted as clear text

Data transmission after login - also in clear text !

“SSH, the Secure Shell is a powerful, softwarebased approach to network security that provides a secure channel for data transmission through a network”

History

Developed by Tatu Ylonen , Helsinki

University of Technology, Finland in 1995 to prevent network attack against University network

Published the protocol SSH-1 as an IETF (Internet

Engineering Task Force) draft

Founded SSH communications security Ltd., in late 1995 (http://www.ssh.com)

Later released SSH-2

What is Secure Shell ?



Powerful, convenient approach to protecting communications on a computer network

 Provides a secure channel for data transmission

 Not a command interpreter

 Provides a secure pipe to open up a command interpreter

What is Secure Shell ? (Contd..)

Supports secure remote logins, secure remote command execution, secure file transfers

Has a client server architecture – SSH server program and client program

Features

Privacy : via strong end-to-end encryption- DES,

IDEA, Blowfish

Integrity : via 32 bit Cyclic Redundancy Check

(CRC-32)

Authentication : server via server’s host key, client usually via password or public key

Authorization : controlled at a server wide level or per account basis

Forwarding : encapsulating another TCP based service such as Telnet within an SSH session

Security Mechanism

Establishing the Secure Connection

The client initiates the connection by sending a request to the TCP port of the SSH server

Server reveals it's SSH protocol version to the client

If the client and server decide their versions are compatible, the connection proceeds

Establishing the Secure Connection (Contd..)

SSH server sends the following to the client - host key, the server key, a list of supported encryption, compression and authentication methods, and a sequence of eight random bytes

Client checks identity of server by using the host key against known hosts database

Client generates a session key and double encrypts it using the host key & server key

Client sends encrypted session key along with check bytes and acceptable algorithm

Authentication

Server then decrypts the encrypted session key it received

Server sends a confirmation encrypted with this session key

Client receives confirmation, confirms server authentication

Client Authentication usually either by Password

Authentication or Public key Authentication

Authentication (Contd..)

Server confirms client authorization

Generates a 256 bit random challenge, encrypts it with clients public key, and sends to client

Client decrypts challenge, generates a hash value with a session identifier (commonly generated random string at beginning of session), and sends to server

Server generates hash, if both match, session is authenticated

SSH2 vs. SSH1

SSH2 has separate transport, authentication, and connection protocols.SSH1 has one monolithic protocol

SSH2 has strong cryptographic integrity check using MAC,

SSH1 has weak checking using CRC-32

SSH2 supports any number of session channels per connection (including none),SSH1 exactly one

Servers running SSH-2 can also run SSH-1 to take care of clients running SSH-1

SSH2 allows more than one form of authentication per session, SSH1 allows only one.

Conclusion

SSH provides a secure channel for data transmission

Provides a secure pipe to open up a command interpreter

Latest version of SSH –SSH3

Threats to E-mail

• Loss of confidentiality.

– E-mails are sent in clear over open networks.

– E-mails stored on potentially insecure clients and mail servers.

• Loss of integrity.

– No integrity protection on e-mails; anybody be altered in transit or on mail server.


Lack of data origin authentication.

Is this e-mail really from the person named in the From: field?

Lack of non-repudiation.

Can I rely and act on the content? (integrity)

If so, can the sender later deny having sent it? Who is liable if I have acted?


Lack of notification of receipt.

Has the intended recipient received my e-mail and acted on it?

A message locally marked as ‘sent’ may not have been delivered.

E-mail security

What are the Options?

Secure the server to client connections (easy thing first) https access to webmail

Protection against insecure wireless access

Secure the end-to-end email delivery

The PGPs of the world

Practical in an enterprise intra-network environment

E-mail security

Email based Attacks

Active content attack

Clean up at the server

Buffer over-flow attack

Fix the code

Trojan Horse Attack

Web bugs (for tracking)

Mangle the image at the mail server

E-mail security

• Software for encrypting email messages has been widely available for more than 15 years, but the email-using public has failed to adopt secure messaging. This failure can be explained through a combination of:

– technical,

– community,

– and usability factors

E-mail security

Why Don’t People Use Email Security?

I don’t because I don’t care.

I doubt any of my usual recipients would understand the significance of the signature.

Never had the need to send these kinds of emails.

I don’t think it’s necessary to encrypt my email.

it’s just another step & something else I don’t have time

E-mail security

Secure E-mail Standards and Products

Other now defunct standards: PEM (privacy enhanced mail), X.400.

S/MIME.

We focus on PGP

PGP

(Pretty Good Privacy)

• Freeware: Open PGP and variants:

– www.openpgp.org, www.gnupg.org

• Open PGP specified in RFC 2440 and defined by

IETF Open PGP working group.

– www.ietf.org/html.charters/openpgp-charter.html

• Available as plug-in for popular e-mail clients, can also be used as stand-alone software.

PGP


“If all the personal computers in the world—260 million—were put to work on a single PGP encrypted message, it would still take an estimated 12 million times the age of the universe, on average, to break a single message.”

PGP


PGP is an e-mail security program written by Phil

Zimmermann, based on the IDEA algorithm for encryption of plaintext and uses the RSA Public Key algorithm for encryption of the private key.

PGP incorporates tools for developing a public-key trust model and public-key certificate management.

PGP


• PGP is an open-source freely available software package for e-mail security. It provides authentication; confidentiality; compression; e-mail compatibility; and segmentation and reassembly.

PGP


PGP Algorithms

Symmetric encryption:

DES, 3DES, AES and others.

Public key encryption of session keys:

RSA or ElGamal.

Hashing:

SHA-1, MD-5 and others.

Signature:

RSA, DSS, ECDSA and others.

PGP


– PGP use:

• public keys for encrypting session keys / verifying signatures.

• private keys for decrypting session keys / creating signatures.

PGP


Security of PGP

There are many known attacks against PGP.

Attacks against cryptoalgorithms are not the main threat

IDEA is considered strong, and while cryptoanalysis advances, it should be strong still for some time.

RSA may or may not be strong. There are recent rumors of possible fast factorization algorithms..

The main threats are much more simple.

PGP


An attacker may socially engineer himself into a web of trust, or some trustable person may change. Then he could falsify public keys. This breaks most of the security.

PGP binaries can be corrupted when they are obtained.

The PGP binaries can be modified in the computer.

The passphrase can be obtained by a Trojan. Weak passphrases can be cracked.

On multiuser system, access to the secret key can be obtained.

Header of Introduction Slider (Heading Font: minion pro, Size:20)

Knowledge is the soul of the universe, as life is to the body. Without one the other is inanimate, savage and a colossal hunk of void matter. A mind that lacks knowledge is like a speeding asteroid floating in space; idle, dead, hazardous and potentially fatal.

Knowledge gives the free floating mind an orbit to follow, life to sustain, a sun to circle and a purpose in the universe. It is the rein of order and freedom to imagine. It is time itself, for the mind writes the future, as every action is first a thought and later a reality. It is the force that fuels the mechanics of life, the machinery of progress.

We at D. Y. Patil University uphold knowledge with such adulation; we worship it as a deity with great reverie. We hold it supreme.

(Body Copy Font: Source sans pro, Size:18)

174 Lecture 1 – Sub Topic Name

Example 1 for Slide with Picture

Mr. Krishnamurti Nair

Chancellor

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ex quo, id quod omnes expetunt, beate vivendi ratio inveniri et comparari potest.

Virtutis, magnitudinis animi, patientiae, fortitudinis fomentis dolor mitigari solet.

Hoc loco discipulos quaerere videtur, ut, qui asoti esse velint, philosophi ante fiant.

(Body Copy Font: Source sans pro,

Size:18)

175 Lecture 1 – Topic Name

Example 2 for Slide with Picture

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Cum praesertim illa perdiscere ludus esset. Item de contrariis.

(Body Copy Font: Source sans pro, Size:18),

176 Lecture 1 – Topic Name

Thank You

PGP

Lecture No: 1

DNS

Chapter

Outline

19-1 NEED FOR DNS

19-2 NAME SPACE

19-3 DNS IN THE INTERNET

19-4 RESOLUTION

19-5 DNS MESSAGES

19-8 ENCAPSULATION

19-9 REGISTRARS

19-10 DDNS

19-11 SECURITY OF DNS

Lecture No: 2

HTTP

Lecture No: 3

Email, SMTP

Chapter

Outline

23-1 ARCHITECTURE

23-2 USER AGENT

23-3 MESSAGE TRANSFER AGENT

23-4 MESSAGE ACCESS AGENT

23-6 WEB-BASED MAIL

23-6 E-MAIL SECURITY

Lecture No: 4

Telnet

Server

Process

Lecture No: 5

FTP

21-1 FTP

Lecture No: 6

Security SSH PGP

Outline

Introduction

History

What is Secure Shell ?

What is Secure Shell ? (Contd..)

Features

Security Mechanism

Establishing the Secure Connection

Establishing the Secure Connection (Contd..)

Authentication

SSH2 vs. SSH1

Conclusion

Thank You

Related documents

Add this document to collection(s)

Add this document to saved

Suggest us how to improve StudyLib