Ch 2

SSL & HTTP security

Prof. Abhishek Vichare

• The Client tries to establish a connection
to the server. (Hello!) The server
responds, that he accepts only secure
communication.
• The Server sends his Public Key to the
Client.
• The Client generates a random value (in
our case it’s 243) and encrypts this
number by using the Server’s public key.
• The Server is the only one that can
decrypt the data with his Private Key.
After decryption, he can read the secret
key (243).
• The transfer of data begins.
• To avoid that the attacker can guess the
secret key (243) it is regenerated from
time to time
• https://howhttps.works/https-ssl-tls-
differences/#:~:text=HTTPS%20is%20the%20secured%20version,'S'%
20stands%20for%20Secure.

• https://www.hostinger.com/tutorials/what-is-ssl-tls-https

• https://www.cloudflare.com/learning/ssl/why-use-https/
HTTP

HTTP is a simple request/response protocol that is used between a client (i.e., browser) and a
Web server . This basically means that the client requests information and the server provides the
requested information using the HTTP.

If a client wants to retrieve a resource (e.g., a static or dynamically created Web page) from a Web
server, it must establish a TCP connection to the corresponding port (e.g., port 80 by default) of the
server and send a corresponding HTTP request message to the server. In essence, the HTTP request
message includes the following components:

• A request method that indicates the purpose of the HTTP request.

The most important request method is GET.

• A reference that indicates the resource to which the method should

be applied (e.g., http://www.esecurity.ch/index.html).
As a working example, consider the situation in which a user wants to retrieve the home page of eSECURITY
Technologies Rolf Oppliger. Therefore, the user simply enters www.esecurity.ch in the browser’s address or
URL field. The browser, in turn, does the following things on the user’s behalf:

1. It uses the Internet Domain Name System (DNS) to retrieve the IP address of the Web server that hosts
www.esecurity.ch.

2. It uses the client system’s IP stack to establish a TCP connection to the Web server. Since the user has not
specified a port number at first place, the browser assumes that the Web server runs at port 80. Any other port
is possible but must be specified in the URL (separated with a colon from the rest of the resource reference).

3. It composes an HTTP request message and uses the TCP connection to send the message to the server (it
assumes the use of HTTP by default).

It is now up to the Web server to process the HTTP request message and to send back a corresponding HTTP
response message.
In the example given above, the browser would compose an HTTP
request message that may look as follows:

GET http://www.esecurity.ch HTTP/1.0

Host: www.esecurity.ch
Proxy-Connection: Keep-Alive
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 4.0)
Accept: image/gif, image/jpeg, ...
Accept-Language: en
...

a typical HTTP response message may look as follows:

HTTP/1.0 200 OK
Date: Mon, 03 Dec 2001 12:10:13 GMT
Server: Apache/1.3.20 (Unix) PHP/4.0.6 FrontPage/4.0.4.3
Last-Modified: Wed, 03 May 2000 08:01:16 GMT
ETag:"81dfc1-14e-390fdccc"
Accept-Ranges: bytes
Content-Length: 334
A proxy server (or proxy) is a forwarding agent, receiving requests for a URL in its absolute form,
rewriting all or part of the message, and forwarding the reformatted request toward the server
identified by the URL.

A gateway is a receiving agent, acting as a layer above some other server(s) and, if necessary,
translating the requests to the underlying server’s protocol.

https://www.seobility.net/en/wiki/Proxy_Server
 User authentication, authorization, and access control

In general, organizations run Web servers to make resources publicly

available and accessible to as many users as possible. In this situation, the
Web servers are typically configured to accept requests from anonymous
users.

• Access to a Web server may be restricted to the employees of an

organization, or certain resources may be accessible only to customers who
have paid a subscription fee or have signed a nondisclosure agreement.
• In these cases, proper user authentication, authorization, and access
control may be required.
following techniques may be used to control access to resources
located on a Web server:
• Restricting access by using hidden URLs (i.e., URLs that are kept
secret);
• Restricting access to a particular group of computers based on those
computers’ address information (i.e., the computers’ IP addresses or
DNS hostnames);
• Restricting access to a particular group of users based on their
identity information and corresponding credentials.
Roughly speaking, setting up HTTP user authentication, authorization, and access control
takes two steps:

1. A file containing the user authentication information must be created. Optionally, the set of
users may be structured in some way (e.g., using groups).
2. The Web server must be told what resources to protect and which users to allow access
(after proper authentication).
 Basic authentication

• the HTTP basic authentication scheme implements password-based

authentication to protect and to control access to the resources of a
server.
• If a browser requests a resource that is protected with the HTTP basic
authentication scheme, the server challenges the browser to provide
some valid authentication information (typically a username and a
password).
Digest access authentication

• HTTP basic authentication scheme must be considered to be weak and

vulnerable, the complementary and inherently more secure HTTP digest access
authentication scheme has been specified

Like the HTTP basic authentication scheme, the HTTP digest access
authentication scheme implements a simple challenge-response mechanism to
verify that the user knows a secret he or she shares with the server (i.e., the
password).

Unlike the HTTP basic authentication scheme, however, the verification is

done without actually sending the secret in the clear.
Instead, the HTTP digest access authentication scheme employs a one-way hash function
(typically MD510) to compute (on the browser side) and verify (on the server side) a digest value
that is used to proof knowledge of the secret.
 • when a browser requests a resource that is protected using the HTTP
digest access authentication scheme, the server challenges the
browser using a nonce (i.e., a randomly chosen value). The browser,
in turn, must respond with a valid digest value to authenticate itself
to the server.
The digest value is computed from the following input parameters:
• The username;
• The user password (or a hash value thereof);
• The nonce;
• The HTTP access method;
• The URL of the requested resource.
Roughly speaking, the digest value is computed as follows:

h(h(A1):nonce:h(A2))

h represents the one-way hash function,

A1 the expression that consists of the username, the realm string, and the user password (each
component separated with a colon), and A2 the expression that consists of the HTTP access method and
the requested URL (again, separated with a colon).
Let us assume that a browser wants to retrieve the index.html file located in the protected directory
/Demo/HTTPDigestAccessAuthentication/ at www.esecurity.ch. Again, the browser does not know that this file
is protected using the HTTP digest access authentication scheme. So it sends sends out a normal-looking
HTTP request message. Remember from our previous discussions that this message may start with the
following request line:

GET http://www.esecurity.ch/Demo/HTTPDigestAccessAuthentication/
HTTP/1.0

All other HTTP request headers remain the same as in the previous example(s). After having received
the HTTP request message, the Web server recognizes that the requested file is located in a directory of
the Web server’s document tree that is protected using the HTTP digest access authentication scheme.
So it returns an HTTP response message that includes the following two characteristic lines (among
other lines and HTTP headers):
HTTP/1.0 401 Unauthorized
...
WWW-Authenticate: Digest
realm="HTTP Digest Access Authentication Demo",
nonce="1011598310"
 The realm parameter carries a string that is displyed to the user so he or she knows which username and
password to use. As illustrated in Figure 2.3 for Opera, most browsers display this string in the prompt in
which they ask the users to type in their username and password.

The nonce parameter carries the random value that is used by the server to challenge the user (or the
browser, repectively).

If the user entered the requested information (i.e., the username and password), the browser would
compute a response value and return it as part of an Authorization header in a second HTTP request
message to the server. In our example, the Authorization header would look as follows:

Authorization: Digest
username="rolf",
realm="HTTP Digest Access Authentication Demo",
uri="http://www.esecurity.ch/Demo/HTTPDigestAccessAuthentication/",
algorithm=MD5,
nonce="1011598310",
response="2cbdf234349bbfbfa8460c2410acb445"
In this header, the response parameter carries the digest
value that is needed to authenticate to the server. It is a
32-bit hexademical value that carries a one-way hash
value
Upon receiving an HTTP request message with a proper WWW-Authenticate header, the server must check the
validity of the response value. In particular, it must look up the A1 hash value that corresponds to the
submitted username, recompute the digest value, and compare the result to the response that was provided by
the browser. If the values match, the user is assumed to be authentic.

Note, however, that the server does not need to know the user password in the clear. It is sufficient for the server to know
the A1 hash value (i.e., the hash value of the username, the realm string,
and the user password).
the HTTP digest access authentication scheme solves the most severe security problem of the HTTP basic
authentication scheme, namely, that passwords are transmitted in the clear (or in Base-64-encoded
form that is equivalent to the unencrypted form).

Instead of sending the username and password to the server, the browser uses the password to properly
compute a response for the challenge provided by the server.

As such, the password is never transmitted across the Internet. Provided that the user has picked a good (i.e.,
hard to guess) password, it is computationally infeasible for an attacker to derive the password from the
response.

For further protection, the user password may not be stored in the clear on the server side (where it could
be stolen by someone with access to the server). Instead, only the hash value of the password may be stored.

As a final precaution, the requested URL is part of the response. Consequently, if the response is intercepted by
an eavesdropper who attempts to play it back to gain illegitimate access to resources, he or she will be able to
get access only to that single URL.

More specifically, he or she will be unable to generate new responses to gain access to resources that are
found in other branches of the document tree. Servers can further protect themselves against replay attacks by
adding a timestamp to the nonces so that responses automatically expire after a relatively short period of time.
• The HTTP digest access authentication scheme is intended as a simple replacement for the HTTP
basic authentication scheme, and nothing more.
• limitations and weaknesses :
 both the HTTP basic authentication scheme and the HTTP digest access authentication scheme are
vulnerable to the man-in-the-middle attack (mainly because the server does not authenticate itself
to the browser before it sends out the challenge)
 the HTTP digest access authentication scheme is (still) a password-based system and suffers from
all the problems of such a system.
 does not provide a complete answer to the need for security on the WWW
 There is a potential difficulty in using an HTTP authentication scheme (i.e., HTTP basic
authentication or HTTP digest access authentication) together with caching mechanisms
implemented by HTTP proxy servers.
 does not provide any data confidentiality or integrity services. This is where cryptographic security
protocols, such as the Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols,
come into play.
 Certificate-based authentication
The SSL and TLS protocols are the security technology of choice for the WWW and,
indeed, most Web applications.

These protocols can be used to have a Web browser and a server authenticate each other,
establish a session key, and use this key to transparently encrypt, decrypt, and authenticate
data segments that are exchanged between them.

Consequently, this protocol can also be used to have a Web server (or HTTP proxy server)
properly authenticate its users.

This makes user authentication and authorization simple and straightforward. On the other
side, however, it also requires that servers and browsers be equipped with public key
certificates.
 Server configuration
Web server software packages usually provide support for user-based and group-based authorization and access
control.

For example, the Apache server allows an administrator to define authorized users, give them passwords, and
place them in groups similar to the UNIX operating system. The syntax that is used to specify access control
rules heavily depends on the Web server software in use.
• Configuring HTTP basic authentication
To protect the contents of an Apache Web server with the HTTP basic authentication
scheme, the following two configuration steps must be completed:
1. A password file must be created. The file must include the names and encrypted
passwords of the legitimate and authorized users of the server. Because the file
contains sensitive information, it should be stored outside of the document tree. To
create and manage the password file, a utility called htpasswd may be used.

This utility creates entries that look as follows (for username rolf and password test):
rolf:yIvSBWSuLs2N2

Obviously, the first field includes the username (i.e., rolf) and the
second field includes the encrypted password (i.e., yIvSBWSuLs2N2).
The password is encrypted using the standard UNIX password encryption function
[i.e., crypt()].
Optionally, a group file may be created to define that certain users belong together and may be
treated as a group (mainly to simplify user management). Each group is defined by a group name
and a list of members (i.e., users).

For example:

family: isabelle marc lara rolf

In this case, a group named family is defined to include the members isabelle, marc, lara, and
rolf.
2. The use of the password and group files must be configured on the server side. There are a
number of server directives that can be used for this purpose:

• The AuthType directive is used to specify the authentication type being used (i.e., Basic or
Digest).

• The AuthName directive is used to specify the authentication realm or name.

• The AuthUserFile directive is used to specify the location of the password file.

• The AuthGroupFile directive is used to specify the location of the group file, if any.

The Require directive is used to specify the requirement(s) that must be satisfied in order to grant
admission.
Let’s have a look at the server configuration that is used to protect the directory
/Demo/HTTPBasicAuthentication at www.esecurity.ch. Protection is invoked by placing the
following .htaccess file in the protected directory:

AuthType Basic
AuthName "HTTP Basic Authentication Demo"
AuthUserFile /home/esecurity.ch/conf/passwords
AuthGroupFile /home/esecurity.ch/conf/groups
require valid-user

The first line indicates the use of the HTTP basic authentication scheme.
The second line specifies the realm string that is used in the prompt to request the user to
enter his or her password.
The third and fourth lines specify the location of the password and group files.
The fifth line requires that any user provides his or her valid password to get access
 Configuring HTTP digest access authentication

To protect the contents of an Apache Web server with the HTTP digest access authentication scheme,
the following two configuration steps must be completed:

1. A password file must be created. For every legitimate and authorized user, the file must include the
username, the realm string, and the user password in possibly encrypted form. Again, the file contains
sensitive information and should be stored outside of the document tree. To create and manage the
password file, a utility called htdigest can be used. It creates entries like

rolf:HTTP Digest Access Authentication Demo:672203b528e0- c29e08df53cba3f51b66

for the username rolf, the realm string ‘‘HTTP Digest Access
Authentication Demo,’’ and the password test.
2. The use of the password and group files must be configured on the server side. In addition to
the directives that are available for the HTTP basic authentication scheme (i.e., AuthType,
AuthName, and Require), the following two directives may be used to configure the use of the
HTTP digest access authentication scheme:

• The AuthDigestFile directive is used to specify the location of the password file.
• The AuthDigestGroupFile directive is used to specify the location of the group file (if any).

For example, the following .htaccess file may be used to protect the
directory /Demo/HTTPBasicAuthentication at www.esecurity.ch:

AuthType Digest
AuthName "HTTP Digest Access Authentication Demo"
AuthDigestFile /home/esecurity.ch/conf/digests
AuthDigestGroupFile /home/esecurity.ch/conf/groups
require valid-user
• https://www.youtube.com/watch?v=ooJSgsB5fIE

• What is Cyber Security? | Introduction to Cyber Security | Cyber

Security Training | Edureka 19

• https://www.youtube.com/watch?v=ca-C3voZwpM

• How Israel Rules The World Of Cyber Security | VICE on HBO 14