About Garlic and Onions a Little Journey…

About Garlic and Onions A little journey…

Tobias Mayer, Technical Solutions Architect

BRKSEC-2011 Cisco Webex Teams

Questions? Use Cisco Webex Teams to chat with the speaker after the session How 1 Find this session in the Cisco Events Mobile App 2 Click “Join the Discussion” 3 Install Webex Teams or go directly to the team space 4 Enter messages/questions in the team space

We are all looking for privacy on the internet, for one or the other reason. This Session is about some technologies you can use to anonymise your network traffic, such as Tor (The Onion Router). The first part will give an introduction and explain the underlaying technology of Tor. We will take look at how you can not only use the Tor browser for access but also how the Tor network is working. We will learn how you can establish a Tor session and how we can find hidden websites and give examples of some websites...So we will enter the Darknet together. Beside Tor, we will also take a quick look at other techniques like I2P (Garlic Routing). In the last section we will make a quick sanity check what security technologies we can use to (maybe) detect such traffic in the network. This presentation is aimed at everyone who likes to learn about anonymization techniques and have a little bit of fun in the Darknet.

CCIE Security #14390, CISSP & Motorboat driving license… Working in Content Security & TLS Security tmayer{at}cisco.com Writing stuff at “blogs.cisco.com”

• How Tor works • Introduction to Onion Routing • Obfuscation within Tor

• Domain Fronting

• Detect Tor

• I2P – Invisible Internet Project • Introduction to Garlic Routing

• Freenet Project

Hide me from Government! Hide me from ISP! Hide me from tracking!

Bypass Corporate Bypass Country Access Hidden policies restrictions (Videos…) Services

Tracking does not require a “Name” Tracking is done by examining parameters your browser reveals https://panopticlick.eff.org

Traffic to external Proxy detected

Combine VPN Service with Proxies Provides additional anonymization Layer You have to have trust in the VPN Provider that they do not log… ☺

https://thatoneprivacysite.net/vpn-section/

• Statement from “Hide-my- Ass”

• “If you do illegal things, we cooperate with Law Enforcement”

• They track the User…

• Chrome Browser leaking real IP because of DNS Prefetching • Despite using a VPN Service…

Enumerating known VPN & Proxy IPs

Bill, stop searching …

Open source SW / public design specs Data is constantly encrypted at multiple layers Sent through multiple routers. Each router decrypts the outer layer and finds routing instructions Sends the data to the next router Result is a completely encrypted path using random routers

• The Tor network consists of relays

• Relays are just nodes where the Tor software is installed

• They build encrypted connections to other relays, forming an overlay network

• Everyone can run a Tor relay and contribute to the network…

• Goal: Provide anonymity and access to censored and/or hidden resources

• Special browser based on mozilla firefox to establish a circuit through the Tor network

• Can connect directly or through proxies

• Often used in combination with VPNs

Tor Dir OR1

OR2

OR3 PK OR1 Web Server PK OR2

PK OR3

Tor Client selects 3 random Routers out of all Tor Relays and get their public keys

OR1

OR2

OR3 PK OR1 Web Server PK OR2

PK OR3

Tor Client sends DH Handshake to OR1, encrypted with public key of OR1, called “relay_create”

OR1

OR2

OR3 PK OR1 SK1 Web Server PK OR2

PK OR3

OR1 completes handshake, symmetric key is created

OR1

OR2

OR3 PK OR1 SK1 Web Server PK OR2

PK OR3

Tor Client sends “relay_extend” to OR1, requesting to extend the circuit to OR2. Keyshare for OR2 is protected by the public key of OR2

OR1

OR2

OR3 PK OR1 SK1 Web Server PK OR2 SK2

PK OR3

OR1 send “relay_create” to OR2, OR2 responds and circuit with symmetric key is created to OR2

OR1

OR2

OR3 PK OR1 SK1 Web Server PK OR2 SK2

PK OR3 SK3

“relay_extend” to OR3, create a circuit

OR1

OR2

OR3 PK OR1 SK1 Web Server PK OR2 SK2

PK OR3 SK3

Web Request follow the circuits

Every hour all Authorities calculate a common status document called the “consensus”

• Very trusted servers that hold the list of all active Tor relays

• Tor client comes with this predefined list and the corresponding public keys

• Every hour they agree on the most recent list of relays (“voting”)

• They create a document called “consensus”. • Each DirAuth publishes and signs its own relay list to all other DirAuth

• Tor client downloads the consenus at first start • Client receives consenus plus hashes of the consenus of all other authorities. Will only trust the consensus if more than half of the hashes match.

• Tor relays can be “Directory caches” where clients can get an updated version of the consensus without the directory authorities

Flags

OR2

OR3

“torrc” = config file

Also use IPv6 relays

Define Geolocation of your ExitNodes

ExitNode from Germany

ClientOnly 1 #never, ever act as an exitNode ExcludeNodes #avoid the nodes / countries listed StrictNodes #if set to 1, Tor will strictly avoid #ExcludeNodes settings EnforceDistinctSubnets #Don‘t select two nodes that are close FascistFirewall 1 #only 80/443 entry & exit nodes EntryNodes # only use those entry node ExitNodes # only use those exit nodes ExcludeExitNodes

OR1

DNS Server OR2

OR3

Tor Exit Relay is responsible for the DNS Resolution

• ISP Resolver • Traversing the least amount of AS • Own Resolver • QNAME Minimization

Bridges are relays that are not announced in the directory servers You can request bridges but will not get the full list 3 bridges are provided

Fingerprint

IP & Port

• Tor Mailbox http://torbox3uiot6wchz.onion/

• Torch http://xmh57jrzrnw6insl.onion/

• The Hidden Wiki http://zqktlwi4fecvo6ri.onion/wiki/Main_Page

• Imperial Library of Trantor http://xfmro77i3lixucja.onion/

• DuckDuckGoGo https://3g2upl4pq6kufc4m.onion/

• The Federalist Paper (Onion v3 Service) http://vww6ybal4bd7szmgncyruucpgfkqahzddi37ktceo3ah7ngmcopnpyyd.onion/

• The Unbelievable tale of a hitman… https://www.wired.co.uk/article/kill-list-dark-web-hitmen

• Hidden Answers Forum http://answerszuvs3gg2l64e6hmnryudl5zgrmwm3vh65hzszdghblddvfiqd.onion/

• Fake Identity Generator http://elfq2qefxx6dv3vy.onion/fakeid.php

• Daniels Onion Link List http://donionsixbjtiohce24abfgsffo2l4tk26qx464zylumgejukfq2vead.onion/onions.ph p

• Matt Traudt’s Blog on Tor http://zfob4nth675763zthpij33iq4pz5q4qthr3gydih4qbdiwtypr2e3bqd.onion/

Onion server

Introduction point

Rendezvous point HS Directory server

Client

Setup hidden service (create public and private key) and create a circuit to chosen Introduction point(s)

IP, Pk Onion server

Introduction point (IP)

Rendezvous point HS Directory server

Client Publish hidden service in six of the directory servers. The servers are calculated based on a function including the consensus status document and the “.onion” address. Repeat once a day (different HSDirs…)

Onion server

Introduction point

Rendezvous point HS Directory server

Client

Client asks one of the directory server for the hidden service. Client gets the public key and the Introduction Points for that service.

Onion server

Introduction point

Rendezvous point HS Directory server

Client

Client selects a random relay node as a rendezvous point

Onion server

Introduction point

message Rendezvous point HS Directory server secret

Client Client contacts the introduction point, requesting to forward the information about the rendezvous point to the hidden server. Message includes a one- time secret

message secret Onion server

Introduction point

Rendezvous point HS Directory server

Client

IP contacts the hidden server, telling him about the RP

Onion server secret

Introduction point

Rendezvous point HS Directory server

Client

Server builds a circuit to the RP, providing the one-time secret from the client

Onion server

Introduction point

Rendezvous point HS Directory server

3 relays from client, 3 relays from server Client

Client communicates to the hidden server via the rendezvous point

FIRST 80 bits of the SHA1 of the 1024 bit Public Key http://xmh57jrzrnw6insl.onion/

Desc ID0 - Predict the selected HSDir relay at a certain point in HSDir time…. n - If you are the selected HSDir HSDir, you can control n+1 access or monitor connections for statistics HSDirn+2

Onion server

http://xmh57jrzrnw6insl.onion/

HS Directory server - The HS Directory server learns your .onion address - Can be used to enumerate hidden servers

SearX with v3 .onion address (52 characters vs. 16 characters) http://ozmh2zkwx5cjuzopui64csb5ertcooi5vya6c2gm4e3vcvf2c2qvjiyd.onion/ Base32 of the complete public key a) Better crypto (replaced SHA1/DH/RSA1024 with SHA3/ed25519/curve25519) b) Improved directory protocol leaking less to directory servers. c) Improved directory protocol with smaller surface for targeted attacks. d) Better onion address security against impersonation e) More extensible introduction/rendezvous protocol f) A cleaner and more modular code base

Add a global value into the HSDir hash function that: - Everyone has agreed upon - Is not predictable

This is done once a day a part of the consensus

The Descriptor is signed by a subkey that prevents the HSDir Server to derive the real .onion address

Only the client , who knows the real .onion address, can derive the real public key

loopback Client App PT Client (Socks)

Obfuscated traffic

loopback Server App PT Client (Socks)

• Obfs2 • Use a additional encryption layer to obfuscate. Key is exchanged in cleartext.

• Obfs3 • Negotiation of a DH Key for obfuscation. Not resistant for active probing.

• Obfs4 • Authenticate with a pre-shared key, distributed out-of-band. Resistant against active probing. Obfuscate with DHE.

• Meek • Obfuscate in http and TLS, leveraging domain fronting

• Using different domain names at different levels

• Leveraging the fact that CDN Network can forward requests that are not in their own domain

DNS TLS A www.google.com SNI: www.google.com

HTTP ….. Host: www.evilrats.com

Hidden domain Front Domain

Using “meek” domain fronting for obfuscation

https://arstechnica.com/information-technology/2018/05/amazon-blocks-domain-fronting- threatens-to-shut-down-signals-account/

Leveraging WebRTC Broker Access via different methods Domain-fronted DNS over HTTPS ☺ Every Browser can act as a proxy via a plugin ☺

Everyone can run a snowflake proxy via plugin

Snowflake is just another PT to select

STUN and DTLS, used by Web RTC (webex teams using same protocols)

First relay, located in russia

SNI Name not really matching the website

CN Name different from SNI String

Issuer, yet another generated domain

Port 9001

Generated strings for common name

Self-signed….

This is another proof that Tor does not really care about the content of the TLS certificates ☺

• SNI String , CN-Name and Issuer are just generated strings…

• Certificates are self-signed

• Purpose of certificates is simply to provide a common method to exchange the keys using the TLS Protocol

• Tor client and relays do not care much about the certificate values

Categories “Pass Through” will still check for certificate errors! Invalid certificate or expired certificate on the server will fail the “Pass through”

Custom URLs (best used for making an exception for decryption) “Pass Through” will bypass all certificate check -> true Pass Through “Decrypt” -> certificates will be checked and the user will get a prompt (“untrusted CA”) Custom categories take precedence over predefined categories!

Default Values provide a good balance between Security and User Experience Remember: EUN in case of a “Drop” requires “Decryption for EUN”! “Drop” : log the certificate error in the access log, decrypt and display EUN “Decrypt” : log the certificate error in the access log, decrypt with a purposely “invalid” certificate and let the client decide if he accepts the connection. “Monitor” : don’t do anything, it’s all on the client to decide…

1513893450.780 65269 192.168.178.55 TCP_MISS/502 39 CONNECT tunnel://85.31.186.98:443/ "tmayer@TOBYLAB" DIRECT/85.31.186.98 - DECRYPT_WEBCAT_7-DEC.TOBYLAB-ID.TOBYLAB-NONE-NONE-NONE-NONE - AUTHM: BASIC DestIP: 85.31.186.98 UAG: - REF: - AUTH: 0 DNS: 0 REP: 925 SFBR: 0 CFBWR: 1176

1513893461.688 76177 192.168.178.55 NONE/504 0 CONNECT tunnel://192.99.11.54:443/ "tmayer@TOBYLAB" DIRECT/192.99.11.54 - OTHER-NONE- ID.TOBYLAB-NONE-NONE-NONE-NONE - AUTHM: BASIC DestIP: 192.99.11.54 UAG: - REF: - AUTH: 0 DNS: 0 REP: 1076 SFBR: 0 CFBWR: 0

1513893461.688 76178 192.168.178.55 NONE/504 0 CONNECT tunnel://154.35.22.9:443/ "tmayer@TOBYLAB" DIRECT/154.35.22.9 - OTHER-NONE- ID.TOBYLAB-NONE-NONE-NONE-NONE - AUTHM: BASIC DestIP: 154.35.22.9 UAG: - REF: - AUTH: 0 DNS: 0 REP: 729 SFBR: 0 CFBWR: 0

1513893471.762 86252 192.168.178.55 TCP_MISS/502 39 CONNECT tunnel://85.31.186.26:443/ "tmayer@TOBYLAB" DIRECT/85.31.186.26 - DECRYPT_WEBCAT_7-DEC.TOBYLAB-ID.TOBYLAB-NONE-NONE-NONE-NONE - AUTHM: BASIC DestIP: 85.31.186.26 UAG: - REF: - AUTH: 0 DNS: 0 REP: 729 SFBR: 0 CFBWR: 1176

1513893509.387 584 192.168.178.55 TCP_MISS_SSL/200 39 CONNECT tunnel://193.23.244.244:443/ "tmayer@TOBYLAB" DIRECT/193.23.244.244 - DECRYPT_ADMIN_MISMATCHED_HOSTNAME_7-DEC.TOBYLAB-ID.TOBYLAB-NONE-NONE-NONE-NONE - AUTHM: BASIC DestIP: 193.23.244.244 UAG: - REF: - AUTH: 0 DNS: 0 REP: 106 SFBR: 0 CFBWR: 138

1513893509.479 766 192.168.178.55 TCP_MISS_SSL/200 39 CONNECT tunnel://185.96.180.29:443/ "tmayer@TOBYLAB" DIRECT/185.96.180.29 - DECRYPT_ADMIN_MISMATCHED_HOSTNAME_7-DEC.TOBYLAB-ID.TOBYLAB-NONE-NONE-NONE-NONE - AUTHM: BASIC DestIP: 185.96.180.29 UAG: - REF: - AUTH: 0 DNS: 0 REP: 195 SFBR: 0 CFBWR: 227 1513893509.761 68 192.168.178.55 NONE/504 0 CONNECT tunnel://37.187.7.74:443/ "tmayer@TOBYLAB" DIRECT/37.187.7.74 - DECRYPT_WBRS_7-DEC.TOBYLAB-ID.TOBYLAB-NONE-NONE-NONE-NONE - AUTHM: BASIC DestIP: 37.187.7.74 UAG: - REF: - AUTH: 0 DNS: 0 REP: 0 SFBR: 0 CFBWR: 0

1515881089.066 605 192.168.178.55 TCP_MISS_SSL/200 39 CONNECT tunnel://149.56.233.142:443/ "tmayer@TOBYLAB" DIRECT/149.56.233.142 - DECRYPT_ADMIN_INVALID_LEAF_CERT_7- DEC.TOBYLAB-ID.TOBYLAB-NONE-NONE-NONE-NONE - AUTHM: BASIC DestIP: 149.56.233.142 UAG: - REF: - AUTH: 0 DNS: 0 REP: 31 SFBR: 0 CFBWR: 136

1515881089.815 356 192.168.178.55 TCP_MISS_SSL/200 39 CONNECT tunnel://89.163.224.250:443/ "tmayer@TOBYLAB" DIRECT/89.163.224.250 - DECRYPT_ADMIN_INVALID_LEAF_CERT_7- DEC.TOBYLAB-ID.TOBYLAB-NONE-NONE-NONE-NONE - AUTHM: BASIC DestIP: 89.163.224.250 UAG: - REF: - AUTH: 0 DNS: 0 REP: 22 SFBR: 0 CFBWR: 46

1515881090.876 419 192.168.178.55 TCP_MISS_SSL/200 39 CONNECT tunnel://185.125.33.58:443/ "tmayer@TOBYLAB" DIRECT/185.125.33.58 - DECRYPT_ADMIN_INVALID_LEAF_CERT_7- DEC.TOBYLAB-ID.TOBYLAB-NONE-NONE-NONE-NONE - AUTHM: BASIC DestIP: 185.125.33.58 UAG: - REF: - AUTH: 0 DNS: 0 REP: 21 SFBR: 0 CFBWR: 78

• Activate HTTPS Proxy

• Tune WSA to handle crypto errors in the log

• Block category “Anonymizers and Filters” • Will not block all connections, but some

• Check logs for a combination of • Reputation blocks and Category blocks • Errors on hostname mismatch • Errors on unrecognized root • Connections to IP • Connections to non-web ports

Block

Self- signed Certificate Certificate Errors Errors

Some relays are detected and classified as Tor Traffic

..and some are not

obfs4 obfuscated traffic Tor relay No App Detected tcp/80

As users go through a web proxy, access logs are generated

Cisco Cognitive Threat Analytics (CTA) Time | IP | URL | User Agent | … 2:45 | 54.62.37.10 | www.google.com | Mozilla (… 2:45 | 68.62.37.10 | www.yahoo.com | Mozilla (… 2:45 | 22.62.37.10 | www.cnn.com | Chrome (… Proxy 2:45 | 59.62.37.10 | www.seznam.com | Mozilla (… HTTP/HTTPS Headers (meta data) HTTP/HTTPS

Distinguishes Tor by time, sequences, and recognition of hidden IP’s

• Stealthwatch downloads Tor directory list of entry and exit nodes every hour

• Cognitive downloads the Tor directory list every hour

• Cognitive analyzes connections on a global basis and tries to identify potential Tor relays • Analyzing certificate details from the TLS Handshake (via Stealthwatch & ETA netflow) • Correlating requests globally • Detection of new relays can come in retrospectively • No complete list of discovered gateways is being kept or exported

The responsible IOC for Tor process

“Onionshare” created “Tor.exe”

Using a builtin Outgoing obfs4 network obfuscated connections bridge from the Tor Browser

Query an Result is the endpoint for a responsible specific IP executable

• Chat application based on Tor Network

• Easy to use, just exchange Tor Client ID

• https://github.com/prof7bit/TorChat

• Forked for Mac OSX ☺

• Enterprise Onion Toolkit https://github.com/alecmuffett/eotk

• https://blog.torproject.org/volunteer-spotlight-alec-helps-companies-activate- onion-services

• https://open.nytimes.com/https-open-nytimes-com-the-new-york-times-as-a-tor- onion-service-e0d0b67b7482

• Potential usecase: Remote Access in your network for SSH (or other protocols)

• Deploy a SSH Server in your network

• Deploy a hidden Tor Server in front

• Doesn’t advertise the public key

• Works behind NAT

• No Open Ports in the firewall

• Leverage Tor Stealth mode

• Each individual accessing gets a separate client key and a separate service descriptor Easy to revoke if access should be blocked

HiddenServiceDir /var/lib/tor/myssh In the server torrc file, After restart of HiddenServiceAuthorizeClient basic choose “basic” tor service myclient HiddenServicePort 3221 12223 or “stealth”

# cat /var/lib/tor/myssh/hostname keesh0ahGh6lahbe.onion auliech8bu7aighaiv4aiW # client: myclient

In the client HidServAuth keesh0ahGh6lahbe.onion auliech8bu7aighaiv4aiW torrc file

• https://tails.boum.org

• Secure OS based on modified Linux

• Only communicates outside via Tor

• Has Thunderbird, Pidgin IM, etc. already preconfigured

• Can be run from USB Stick

Basic security:

• Disable automatic launch of scripts by using setting of “safest”

• Avoid darknet sites that do not offer HTTPS

• Do not reuse same logins on darknet and clearnet! (Silk Road..)

• Communicate using PGP (email, IM, etc…) Intermediate security = Basic security plus

• Use Tor over VPN

• Learn to use bridges with Tor

• Use a safe OS like “Tails” High Security = Intermediate security plus

• Dedicated, trusted hardware (no virtual image)

• Use Qubes https://www.qubes-os.org/

• Ross Ulbricht, the mastermind behind Silk Road

• On October 11, 2011, an account named “altoid” posted on bitcointalk.org a thread titled “a venture backed bitcoin startup company”, looking for partners for a bitcoin startup. Altoid referred people to contact him at [email protected]. He also discussed the “Silk Road” marketplace in the thread. Shortly after, Silk Road was advertised on the forum “shroomery.org” by a user also named “altcoin”.

• Ross’s Youtube channel and Google Plus page included links to Mises Institute, an Austrian blog that published content related to the economic theory. On the Silk Road forum, DRP also backlinked to Mises Institute and shared the site’s content there. Through one of these posts, he mentioned that his time zone is the (PT), i.e. the Pacific Time zone.

• Ross posted on Stakoverflow this question “How can I connect to a Tor hidden service using curl in PHP?”. Initially, Ross posted the question using an account aliased with his real name, yet less than a minute later, the account’s alias was changed to “frosty”.

• Ross bought 9 fake identification documents that included his real picture, yet different names. The US border customs intercepted the package which had been shipped from Canada to Ross’s apartment in San Francisco.

• Packet-switched anonymous network layer (ard. 70K users)

• Distributed Network database of routers (no Directory Servers)

• Provides anonymous web browsing, chat, email, IM, file sharing, …

• Opensource

• Built as its own hidden network, not as an anonymization tool

• Using UDP for transport

• Java based

• Every routers has one or more inbound and outbound tunnels

• Lifetime of 10 min

• Routers are both relays and nodes • Relay: forward other message to other routers • Nodes: sending or receiving messages for themselves

• Inbound tunnels require port forwarding for optimizing throughput • Cumbersome to use within corporate networks (but not impossible ;) )

NetDB 3 Alice: 1,2 4 Simon: 3,4 InboundTunnels Bob: 5,6 1 Simon 2

Alice 5 6 Outbound Tunnels Bob

• Super-Peers (aka floodfill peers) hold a network database (distributed hashtable)

• This contains two informations : “routerInfo” and “leaseSets”

• routerInfo – stores information on specific I2P routers and how to contact them (public key, identifier, contact information)

• leaseSets – stores information on a offered service (i.e. I2P websites, email servers, etc.); entry point of a specific tunnel

• Initial set of active peers is loaded from some public sources • Hardcoded into the software

• Every router collects a local statistic of other active peers

• When a router is successfully selected for establishing a tunnel, key exchange is happening

• Each message sent can be sent through any other router

• Several different messages can be sent within one encrypted packet

• Similar to Garlic that can hold several cloves

Many cloves inside the “head”

Garlic Cloves

Alice Peter Jan

NetDB

Build tunnel Build tunnel

Alice Peter Jan

NetDB

CONNECT Tunnel

Alice Peter Jan Clara Simon Bob

NetDB

Garlic

Outbound Tunnel Inbound Tunnel

Alice Peter Jan Harry Eve Clara Simon Bob

Tunnel Encryption: AES Transport Encryption: DH + AES

Garlic Encryption: El Gamal + AES

All nodes act as a router

Point your browser to your local I2P router

Accessing hidden websites within the I2P network I2P is mainly about hidden websites, NOT so much about reaching the cleartext internet

I2P recommends to poke a hole in your firewall for incoming traffic udp/ tcp/ Will dramatically improve performance

Can be defined on ANY Port!

Lot of requests for udp/23852…(but remember, port defineable…)

Classified as P2P File Traffic

I2P is java based….

• https://www.cdc.informatik.tu- darmstadt.de/fileadmin/user_upload/Group_CDC/Documents/Lehre/SS13/Seminar/ CPS/cps2014_submission_4.pdf

• https://geti2p.net/en/docs/how/tech-intro

• http://hor6372x6soyyts2.onion/mirrors/HiddenWikiClean/A_Radical's_Introduction_t o_Anonymity.html#Weaknesses

Completely distributed network of ard. 10K nodes Main purpose is to anonymously store and retrieve data Data is stored in encrypted chunks on multiple servers Data is inserted into the “network”, original uploader can go offline The “network” does not delete data actively but will only forget data if it is not requested after some time

Offers a “Opennet” and “Darknet” mode Opennet: Peers are constantly searching for other peers and stored information Darknet: Each peer is only giving out his key to other known peers directly

• Files are stored in encrypted chunks, no 1 File 3 File node has the complete File ? 2 File ? file

File ? • Chunks are cached on the path to the requestor File ? 4 (at least in a 3 nodes

File distance) 5 • This results in files being requested very often to scale better • Protocol is UDP based

Freenet in “Openmode” uses predefined seednodes. Access some via DNS, can potentially be picked up…

Classified as P2P file traffic

Some IP are classified as Freenet Client

• https://en.wikipedia.org/wiki/Freenet

• https://freenetproject.org/pages/about.html

Blocking Tor completely is very hard, but a check on TLS certificate errors can provide some decent blocking & visibility for enterprises Combination of netflow analysis, anomaly detection & certificate checking on the gateways is probably your best bet Leveraging Stealthwatch with CTA and ETA Combine it with AMP for Endpoints for further analysis and visibility Other Tools like I2P and Freenet exist, but purpose is to exchange information, not so much for anonymizing your browsing I2P optimizing performance over special ports that need to be open No support over web proxies with I2P Port-forwarding on firewalls is recommended for I2P -> cumbersome to use within corporate environments Freenet purpose of sharing information with the public

Hide me from Government! Hide me from ISP! Hide me from tracking!

Bypass Corporate Bypass Country Access Hidden policies restrictions Services

BRKSEC-2011 © 2020 Cisco and/or its affiliates. All rights reserved. Cisco Public 154 Complete your online session • Please complete your session survey survey after each session. Your feedback is very important.

• Complete a minimum of 4 session surveys and the Overall Conference survey (starting on Thursday) to receive your Cisco Live t-shirt.

• All surveys can be taken in the Cisco Events Mobile App or by logging in to the Content Catalog on ciscolive.com/emea.

Cisco Live sessions will be available for viewing on demand after the event at ciscolive.com.

Demos in the Walk-in Cisco campus self-paced labs

Meet the engineer Related sessions 1:1 meetings