I recently had an issue with a Tomcat server taking very long to restart. It was bizarre because when the system was starting, the Tomcat server was taking about 20-30 seconds to start, but a subsequent Tomcat restart was taking 20-30 minutes.
The logs indicated that the following step was taking a lot of time:
INFO: Creation of SecureRandom instance for session ID generation using [SHA1PRNG] took [135172] milliseconds.

This lead to the Tomcat page with advice on faster startup. The problem was – Tomcat was using /dev/random as source of randomness, and when the entropy pool was exhausted, this device was blocking.
This explained why the problem was not manifesting right after system restart: because of the associated ‘noise’, there was a lot of entropy. But after the system was stable, the entropy pool was depleted.

The solution to this is to tell Tomcat to use the non-blocking /dev/urandom device instead of /dev/random:

When read, the /dev/random device will only return random bytes within the estimated number of bits of noise in the entropy pool.

A counterpart is /dev/urandom (“unlimited”) which reuses the internal pool to produce more pseudo-random bits. This means that the call will not block, but the output may contain less entropy than the corresponding read from /dev/random.
wikipedia

So, to make Tomcat use /dev/urandom you have 2 options:
1. As indicated in the Tomcat slow startup troubleshooting guide: Configure JRE to use a non-blocking entropy source by setting the following system property: Djava.security.egd=file:/dev/./urandom

2. Change the $JAVA_HOME/jre/lib/security/java.security settings file:
securerandom.source=file:/dev/urandom
instead of
securerandom.source=file:/dev/random

More about entropy

(more…)

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…)