Tomcat Notes: Web Security

This is a personal study notes of Apache Tomcat. Below are main reference material.

- YouTube Apache Tomcat Full Tutorial，owed by Alpha Brains Courses. https://www.youtube.com/watch?v=rElJIPRw5iM&t=801s

  • 1、Overview
  • 2、Two Levels Of Web Security
    • 2.1、Trace Of A Full Security Example
  • 3、Some Security Conceptions
    • 3.1、Man-In-The-Middle
    • 3.2、 Key Store And Trust Store
    • 3.3、Message Digests
    • 3.4、Symmetric Encryption And Decryption
    • 3.5、Asymmetric Encryption And Decryption
  • 4、Process Of HTTPS

1、Overview

This article is about problems in web security, how HTTPS secure sending messages and some basic cryptology algorithm.

I’m not very confident with this article since I never make any practice on those concetions or theorys.

Any advice or correction is welcomed.

2、Two Levels Of Web Security

Web server and web app security covers two distinct but related levels.

  • Wire-level(transport-level): In this level it encrypts data transmission through all nodes.
  • Users/roles security: User authentication and role authorization. Good news is Tomcat supports ‘Container-managed security’ in which Catalina, rather than a particular web app does this heavy lifting.

HTTPS is a way to secure in this two levels. HTTPS is a way to secure in this level. S of course stands for secure, There a lot of layers atop HTTPS but HTTPS is the most popular and dominant one.

Tomcat uses HTTP by default. We need to turn HTTPS on in TOMCAT_HOME/conf/server.xml. And other operations are also required.

Three problems HTTPS need to solve.

1. The one who sends you messages is who you think it is rather than other one who pretends to be it.
2. The messages are encrypted, even though other people capture the messages but we have the confidence they can't decrypt it.
3. The request(response) recieved by the server(the browser) is exactly same with initially sent by the brower(the server).

Here is the wire-level security and services in Alice-to-Bob messages sending scenario.

  1. Peer Authentication (aka mutual chanllenge)

     messages            #Is it real Bob?
 Alice <------------->Bob
 #Is it real Alice?

  2. Confidentiality (message decryption/encryption)

            message                          encrypted message                   message
 Alice --------->encryption engine------------------>decryption engine--------> Bob

  3. Integrity:

           message		 message
 Alice--------->route------->Bob # does sent messge == recieved message?

2.1、Trace Of A Full Security Example

We are going to explore the details of web security with curl. The curlis used to issue a request over a HTTPSto a deployed web app.

Below is the output of curlissuing a HTTPSrequest.

* About to connect() to localhost port 8443 (#0)  # 8443 is the conventional port fo HTTPS in Tomcat
*   Trying ::1... connected						  # while 8080 is for HTTP
* Connected to localhost (::1) port 8443 (#0)
* successfully set certificate verify locations:
*   CAfile: none		
  CApath: /etc/ssl/certs		#Exchange for certificates
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):	#In handshake, the server and the client need to discuss
* SSL connection using EDH-RSA-DES-CBC3-SHA # which encryption to use and digital certificates.
* Server certificate:	
    ...
*   SSL certificate verify result: self signed certificate (18), continuing anyway.  
* Server auth using Basic with user 'moe'
# one the SSl and TLS secure the connection, server begins to handle request
> GET /predictions HTTP/1.1
> Authorization: Basic bW9lOk1vZU1vZU1vZQ==
> User-Agent: curl libcurl OpenSSL zlib libidn
> Host: localhost:8443
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: Apache-Coyote/1.1
< Cache-Control: private
< Transfer-Encoding: chunked
...
<
<html>

3、Some Security Conceptions

3.1、Man-In-The-Middle

Man-in-the-middle scenario.

Alice(sender)---------------------->Bob(intended recepient)
						|
						|	
				Eve(eavesdropper)

Alice sends messages to Bob and Alice thinks the person she sent messages to is Bob but it is Eve in fact.

Bob thinks he receives messages from Alice but it is Eve in fact.

This is where peer authentication phase come in. It is meant to build trust on the Alice and Bob sides. In other words Alice
sends certificates to Bob to assure Bob that it is really Alice on the other side and Bob do the same thing to Alice to get trust.

3.2、 Key Store And Trust Store

Now let me intrduce more jargon which are key storeand trust store.

Java uses this terminology all over the place and it is also what we are going to use.

They bear directly on the topic of digital certificates.

The key storeis where we keep our digital certificates. So it’s database of our digital certificates. They are just some files.

The trust storeis database of digital certificates that I trust. The trust stroecould be the same with key storeby the way.

3.3、Message Digests

We see this thing before. When we download the Tomcat from Apache official site, we can see sha-1or md5used to verify the integrity, making sure the package we download has exactly same with that in Apache server.

By the way output of the Message Digestcould be encrypted forming a digital signature.

请添加图片描述

Below is the processes of sending a message, and Message Digestis part of the encryption engine.

在这里插入图片描述

3.4、Symmetric Encryption And Decryption

Now we are going to get further about the encryption keyand the decryption key.

In the modal called Symmetric encryption and decryption, encryption keyand decryption keyis the same one.

It brings a new problem, if Alice has the single key, how can she manage to send the single key to Bob safely or vice versa?

That’s sometimes called the key distribution problem.

The upside of this modal is that it’s fast. Roughly speaking it 1000 times faster than Asymmetric encryption and decryption.
请添加图片描述

3.5、Asymmetric Encryption And Decryption

In this modal, it uses a pair of key, containing a public keyand a private key, to encryption and decryption.

This pair of key is generated by the recipient. The public keyis used to encryption and the encrypted message can be decrypted only with the private key.

The pulic key can be held by anyone just like its name so it basically can be percieved as an indentity, while the private name can only be held by the recipient.

Supposing Alice wants to send a message to Bob.

  1. Alice firstly get Bob’s public key.
  2. Alice encrypts message with the public key.
  3. Bob recieves the encrypted message then decrypts it with it’s private key.

In this way it assure Alice that her messages can be understood only by Bob.

While it’s not perfect, Alice knows who she sent messages to but Bob does’t know where the messages come from.

请添加图片描述

4、Process Of HTTPS

With the basis of above conceptions we are going to get into how ‘S’ in HTTPSworks.

Three terms play a role in wire-level security ‘peer authentication’ in particular.

  • Key Pair: A pulic key and a private key. Unlike the asymmetric cryptology, the public key in here is used to decryption while the private key is used to encryption.

  • Digital Certificate: Including the key pairand a digital signature as a voucher for message sent by someone.

    Digital signature is a message digest encrypted by the private key.

  • Certificate Authority: Company that voucher for a digital certificate.

    Company voucher for a DCby adding it’s digital signature to the DC.

HTTPS addresses the man-in-the-middle by having the two sides(Alice and Bob) exchanges their DCto confirm their indenties.

Here’s is the five steps that Alice would go through in order to send messages to Bob.

  1. Alice sends a signed certificate reqeust containing her name her public key and perhaps some additional information to a CA.
  2. The CAcreates a message M from Alice’s request. signing the message M with its private key, thereby creating a seperate signature message SIG,
  3. The CAreturns Alice the message M with its signature message M. Together M and SIG form Alice’s certificate.
  4. Alice sends her newly minted certificate to Bob to give him access to her public key .
  5. Bob verfies the signature SIG using the CA'spublic key. If the signature proves valid, which means the message does come from Alice, he accepts the public key in the certificates as Alice’s public key which is her identity.