2017-07-13 21:47:03
good
Start testing the protocheck system
Blackhole has a neat feature. You can write protocol checker programs with a twist. Normally protocol checkers
are some sort of proxy sitting between the web and the application. While they add some security, protecting the
applications from abuse, they can be a liability. They can have bugs too. In the worst case scenario, the attacker may gain control
of the protocol checker and becomes effectively a "man in the middle.”

Since protocol checker are sitting after the SSL server, they have access to the full communication in clear. A pretty good place
to be if you are a "man in the middle.”

Blackhole propose a twist. When you define a rule connecting the SSL server to the web server, you can define a fork, creating
a connection to a protocol checker. This protocol checker may be installed anywhere in the network (as controlled by Blackhole).
Ideally, it runs in a container with zero connectivity. It accepts connection from blackhole and this is all it can do.

The twist is interesting. The protocol checker is not a proxy. It is sitting on the side.

*It receives connections.
*It receives the payload.
*And it returns the number of bytes (the offset) that has been validated so far.
*Or it simply hangup, terminating the connection to the application.

The blackhole does this processing.

*It establishes a connection to the application
*It establishes a connection to the protocol checker
*It receives some data. It transfers the data to the checker
*The checker validates the data and returns the amount of data the blackhole is allowed to send to the application.

So the checker can't modify the data, can't talk to the application. If an attacker tricks the checker and takes control,
he is not a "man in the middle.” It can collect various information from the payload, but can communicate with anyone else
(zero connectivity).

Protocol checkers are very simple programs.