MR. SMITH
explorative notes on whatever I'm doing now
TLS Handshake
Below you will find a brief description of the TLS handshake process. A TLS session always establishes that the Server is who it says it is. However, the Server can also request or require that the Client proves that it is who it says it is. This can be configured as CLIENT_AUTH: WANT
or CLIENT_AUTH: NEED
. This Client authentication process is referred to a Client Auth or Mutual Auth (since Server Auth is always implied).
Server Authenticated TLS
This flow describes the regular TLS handshake process where Server Auth is implied
Client Hello: Client -> Server
- Client sends Server the highest TLS version it supports
- Client sends Server the cipher suites that it supports
Server Hello: Client <- Server
- Server sends Client the agreed upon TLS version for the session
- Server sends Client the agreed upon cipher suite for the session
- Server sends Client its Certificate which contains its public key
Client Key Exchange: Client -> Server
- Client validates that Servers certificate is signed by a trusted CA
- Client validates that the Server hostname matches that in the certificate
- Client extracts the Servers public key from the certificate
- Client generates a session key using the agreed upon cipher suite and TLS version parameters
- Client encrypts the session key in the Server’s public key
- Client sends the Server the encrypted session key
Client Finished: Client -> Server
Server Finished: Client <- Server
Encrypted Message Transfer: Client <-> Server
Client or Mutually Authenticated TLS
This section describes a Client or Mutual Auth Handshake. The new actions are in bold
Client Hello: Client -> Server
- Client sends Server the highest TLS version it supports
- Client sends Server the cipher suites that it supports
Server Hello: Client <- Server
- Server sends Client the agreed upon TLS version for the session
- Server sends Client the agreed upon cipher suite for the session
- Server sends Client its Certificate which contains its public key
- Server requests Client certificate (Client or Mutual Auth)
Client Key Exchange: Client -> Server
- Client validates that Servers certificate is signed by a trusted CA
- Client validates that the Server hostname matches that in the certificate
- Client extracts the Servers public key from the certificate
- Client generates a session key using the agreed upon cipher suite and TLS version parameters
- Client encrypts the session key in the Server’s public key
- Client sends the Server the encrypted session key
- Client sends Server the clients certificate if it has been requested
Server Validates Client
- Server validates the Clients certificate is signed by a trusted CA
Client Finished: Client -> Server
Server Finished: Client <- Server
Encrypted Message Transfer: Client <-> Server
fs2 (functional streams for scala)
I have worked with fs2 a bit over the past year, but this month I have begun to take the time to more fully understand the api. When using working with fs2 streams, as with functional programming in general, it is desirable to push all side effects to the edge of the runtime universe.
Basic Architecture
In designing this sample application, it is my intent to use software best practices. I will first set out to model my domain objects, ComicBook
and Order
case class ComicBook(
title: Title,
publisher: Publisher,
authorName: AuthorName,
isbn: ISBN,
available: Boolean,
price: Price)
case class Order(
comic: ComicBook,
orderDate: DateTime,
shipDate: Option[DateTime] = None,
status: OrderStatus = OrderStatus.Opened)
These objects will be available for CRUD operations via endpoints implemented in http4s
These endpoints will be serviced by a ComicBookService
and OrderService
with will interface with repositiory interpreter implemented with doobie
to persist the domain objects
… a bit about the tech stack
- http4s (http server)
- cats (functional library for scala)
- fs2 (stream library)
- doobie (jdbc interface for scala)
What’s this all about
This project will create a Java Pet Store analog called Scala Comic Shop where I will develop an application using idomatic functional scala techniques and blog my notes and findings.