User 1 (Alice): generates private and public key, stores her private key in a secure location, sends the physical data to Registration Authority (RA) for verification
Registration Authority: verifies the user data and informs the Certification Authority (CA)
CA (the trusted authority): signs the Alice public key with its own private key (issuing a digital certificate) and publishes it
User 2 (Bob): looks up the Alice public key and verifies its authenticity with the CA
Communication: Bob sends Alice a message by encrypting it with Alice public key

At this stage Bob knows that the public key that he sees is really the one of Alice. But is it really Alice he is talking to? Here is how to find out:
– Bob asks Alice to encrypt for her a random message
– Alice encrypts this message with her private key
– Bob decrypts this with the Alice public key (which he knows it belongs to Alice because he trusts the CA)
– if the decrypted message is the same as Bob sent, then it must be really Alice herself
And this is how every SSL conversation begins 🙂

PKI in plain English (PPT, 0.7M)

1. Aspect oriented programming (AOP)

In the wikipedia example about AOP, transactions, security and logging represent cross-cutting concerns. If we need to change one of these (ex. security) – then it will be a major effort, since the concerns are tangled and the related methods appear scattered around all the code.

AOP attempts to solve this problem by allowing to express cross-cutting concerns in stand-alone modules called aspects. Aspects can contain
– advice – code joined to specified points in the program and
– inter-type declarations – structural members added to other classes.

Drawbacks: If a programmer makes a logical mistake in expressing crosscutting, it can lead to widespread program failure.
Conversely, another programmer may change the join points in a program in ways that the aspect writer did not anticipate, with unforeseen consequences.

2. HTTPS and MTU Path discovery

I recently encountered this interesting problem with HTTPS and MTU. It is explained entirely by Mark Maunder – ‘Routers treat HTTPS and HTTP traffic differently‘. I will just summarize it:
– HTTPS servers set the ‘Do not fragment’ IP flag
– if a server sends a big HTTPS packet and a router does not allow that packet size, then the router will not break that packet (see previous point).
– so the router will simply drop the packet and send back an ICMP (Internet Control Message Protocol) message telling the host to reduce the MTU size and resend the packet
– but if the network administrator decided to block all the ICMP traffic, then the host will never see the problem
– the solution in my case was to decrease the MTU size (1400)

The same issue described also here.

3. Information security standards

(more…)

The initial communication in a HTTPS connection relies on a traditional D-H key exchange – which will serve as symmetric encryption key for the rest of the HTTPS conversation.
The outline of the handshake is:
– client/server hello: list the available encryption algorithms
– certificate exchange
– certificate validation
– key exchange
– finished

Here is the process explained in layman words:

1. Client sends a Client hello message to the server with some metadata (TLS version, cipher algorithms, compression methods)
2. The server replies with a Server hello message to the client with the corresponding metadata + the Server public certificate signed by a CA.
3. The client verifies the server digital certificate and cipher a symmetric cryptography key using an asymmetric cryptography algorithm, attaching the server public key and an encrypted message for verification purposes.
4. The server decrypts the key using its private key and decrypts the verification message with it, then replies with the verification message decrypted and signed with its private key
5. The client confirm the server identity, cipher the agreed key and sends a finished message to the server, attaching the encrypted agreed key.
6. The server sends a finished message to the client, encrypted with the agreed key.
From now on the TLS session communicates information encrypted with the agreed key
https://github.com/alex/what-happens-when

The same process – explained in full details.

Note: Excepting the initial TLS handshake, the other HTTPS content (headers + payload) is encrypted with the key agreed during the TLS handshake.