Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

collect statistics about CA #139

Open
evilsocket opened this issue Apr 13, 2018 · 4 comments
Open

collect statistics about CA #139

evilsocket opened this issue Apr 13, 2018 · 4 comments
Assignees
Labels
feature a whole new feature

Comments

@evilsocket
Copy link
Owner

evilsocket commented Apr 13, 2018

while apps are creating TLS connections, the daemon should (asynchronously) reslove the whole certificates chain of every visited host and collect statistics about what certification authority is being used for each one (incrementing its connection counter in a new by_ca map[string]int field. These new stats should be rendered as a new tab in the UI.

@evilsocket evilsocket added the feature a whole new feature label Apr 13, 2018
@evilsocket evilsocket self-assigned this Apr 13, 2018
@evilsocket evilsocket added this to the 1.0.0 milestone Apr 13, 2018
@akatasonov
Copy link

not bad, haven't seen these stats anywhere else!

@evilsocket
Copy link
Owner Author

yeah, i'm personally very curious to see from whom my traffic is protected and encrypted ...

@aes512
Copy link

aes512 commented Apr 17, 2018

This would be GREAT! Fantastic idea ;-)

@evilsocket
Copy link
Owner Author

Removed this from the 1.0.0 milestone as it'll take more time than I initially thought. There're two ways of handling this:

  1. Whenever a new TLS connection is detected, the daemon can asynchronously connect to the same host and fetch the certificates chain, this adds a lot of overhead and it's generally slow. <-- This is not the correct approach

  2. TLS handshake packets should be intercepted on the Netfilter queue and the Certificates section parsed and extracted from them. The problem is that the whole handshake takes more than just one packet, so the system should collect, reassemble and then parse when the end of the handshake is reached (there's a specific marker for it). <-- This is

The second approach is being developed on the passive-tls-query branch.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature a whole new feature
Projects
None yet
Development

No branches or pull requests

3 participants