tor-dev February 2016

tor-dev@lists.torproject.org

44 participants
58 discussions

Set up Tor private network
by SMTP Test 02 Mar '16

02 Mar '16

Hi all, I try to set up a Tor private network. I found two tutorials online ( http://liufengyun.chaos-lab.com/prog/2015/01/09/private-tor-network.html and https://ritter.vg/blog-run_your_own_tor_network.html) but seems that they both are outdated. Could anyone please give me a tutorial or some hints on building a private Tor network? Another question is: what is the minimum number of required directory authorities for a private Tor network? I am wondering if one directory authority is enough. Thanks

3 3

[Vidalia Bundle] Linux support
by Yaroslav Pronin 29 Feb '16

29 Feb '16

Hello. Why Vidalia Bundle doesn't support Linux? A few years ago there was Vidalia for Linux (https://dist.torproject.org/vidalia/), but its development stopped abruptly. I'm maintainer Vidalia package in the AUR and concerned about the fate and future development of the GUI client. Whenever possible, I would have been able to help support the implementation of Linux in the Vidalia Bundle, or to take care of Vidalia (https://dist.torproject.org/ vidalia/) and maintain it.

1 0

Stopping the censoring of tor users (via exit bridges / proxies / OpenVPNs)
by grarpamp 29 Feb '16

29 Feb '16

On 2/25/16, blacklight . <pandakaasftw(a)gmail.com> wrote: > hello there! i don't know if this mailing list works but i thought of > giving it a try. > > i was lately reading an article ( > http://www.pcworld.com/article/3037180/security/tor-users-increasingly-trea… > ) > and it was about tor users getting blocked from accessing alot of website. > but after giving this some thought i think i came up with a possible > solution to the problem :there is a thing called bridges, they are used to > access the tor network without your isp knowing that you use tor, but if > you can use those proxies to enter the network, it might also be possible > to exit the network with them. But then we face a second challenge, the > exit nodes have to be configured in such a way that it will relay traffic > to such a bridge, so the exit node owners also need to know the ip of the > bridge. While this doesn't seem difficult to do, it can become difficult. > You see if the bridges are published on a public list(like normal bridges > are) then the blocking sites in question will be able to block those > address too. While this also posses a problem, a possible solution could be > found in something called flashproxies, flashproxies are bridges with a > really short life span, they are created and destroyed fairly swiftly, when > this is done in a rapid pace, they become really hard to block because the > ip changes all the time. So if the exit nodes can be configured to make use > of such flash proxies, then the problem could be solved. I Must admit that > not an expert on this or anything, and it needs alot of more thought, but > it could work. so i was wondering if there are any experts who could help > me with thinking out this subject and maybe confirm if this idea could > work. Skipping that whoever wants to enumerate, test, block, and share lists of the IP of your final hop will find a way to do so... "flashproxies" - are essentially illegal to use as the operator got stupid, and didn't gave permission. - are unstable as were never intentionally provisioned, and the operators get smart when abuse reports and shut them off. - proxy lists are going to be a pain for you to scrape and maintain Options - run your own volunteer network of last hop "proxies" / bridges - buy them from AWS or wherever "meek" style - partner with or plug into already existing networks of those - get tor relays or bridges to do this I previously wrote in archives that exit relays could bind OpenVPN to extra IP's they configure on their exit relay boxes. Tor daemon has nothing to do with those IP so they never appear in tor's easily blacklistable consensus. Users then OpenVPN over tor to those via use of the relay fingerprint to reach vpn terminator IP over relay localhost to save bandwidth, and on out to clearnet. You can OpenVPN to some list of onions if you don't feel like listing the relay fingerprints / extra input IP's on wikis. But it's not going to stop dedicated blacklisters, and onion doubles bandwidth use. However it could also be used by non-exits that for whatever reason didn't want to be a tor-exit but did want to offer exit via some remote third party vpn service. And strictly social sharing on forums etc could happen for distribution. There are already some exits that for various reasons, intentional or other, do not exit from their OR IP. That is a feature that some tor users do now find and use. And relays don't offer OpenVPN yet which would also give users more than just IPv4-TCP exit scheme. Though it is integrated somewhat, I2P has this manual sort of exit offering model with false.i2p and a few other nodes. [Doesn't seem to require daemon dev work, updated subject, continuing thread reply to relays and talk.]

1 0

Leif's important piece on update golden keys
by Nathan Freitas 28 Feb '16

28 Feb '16

The issues in this timely story came up a number of times today at Tor Dev as a threat model we must take more seriously. Fortunately, thanks to Tor Browser, Lunar, Holger, Hans, Fdroid and others, we are making real progress. http://arstechnica.com/security/2016/02/most-software-already-has-a-golden-…

2 1

Is tor-wiki-changes ML dead?
by nusenu 27 Feb '16

27 Feb '16

Hi, tor-wiki-changes doesn't seem to send out any emails? https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-wiki-changes https://trac.torproject.org/projects/tor/ticket/18262

2 4

Relay Database: Existing Schemas?
by nusenu 26 Feb '16

26 Feb '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, I'm planing to store relay data in a database for analysis. I assume others have done so as well, so before going ahead and designing a db schema I'd like to make sure I didn't miss pre-existing db schemas one could build on. Data to be stored: - - (most) descriptor fields - - everything that onionoo provides in a details record (geoip, asn, rdns, tordnsel, cw, ...) - - historic records I didn't find something matching so far, so I'll go ahead, but if you know of other existing relay db schemas I'd like to hear about it. thanks, nusenu "GSoC2013: Searchable Tor descriptor archive" (Kostas Jakeliunas) https://www.google-melange.com/gsoc/project/details/google/gsoc2013/wfn/ 5866452879933440 https://lists.torproject.org/pipermail/tor-dev/2013-May/004923.html https://lists.torproject.org/pipermail/tor-dev/2013-September/005357.htm l https://github.com/wfn/torsearch (btw, someone knows the license of this?) > This is true: the summary/details documents (just like in Onionoo > proper) deal with the *last* known info about relays. ernie https://gitweb.torproject.org/metrics-db.git/plain/doc/manual.pdf (didn't find db/tordir.sql mentioned in the pdf) "Instructions for setting up relay descriptor database" https://lists.torproject.org/pipermail/tor-dev/2010-March/001783.html "Set up descriptor database for other researchers" https://trac.torproject.org/projects/tor/ticket/1643 -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVLrmVAAoJEFv7XvVCELh0+ycP/0VkRWMGAhx7YwWhixtOPB0q ouitosse3SdLCMd1W7cps7nnQhcGv8E1xeUPYeizNQ+RIK9ldvnwgxhVt9ETOI3e oL6bcx3B/NSbTcGfZhIU6XCCX7+39CXz3/+/gXg4c1a5Cd9rYKuwTn7ZApPUNAK2 9yfckCwHaqh67ZDHB1A7nrHX1BJAjwhri5JRGomHSUXPwNZOyMzpgPkB+I92esqc Z4ajQo2D+Vyk42qF7apqp5ApVBLdt5ycUtW1j4s4KvyJH2BjeP4tCXvvYLKv9IvN TGHMJ111NQXbuk6H1OdaDmMZhhW6utPk8YAbNc7RZHqCdH7No40zFVlikLDrV2Xl uLt8FMlck7hGQv/4udA59Dw3PGHfrSiCbvJXb0S2jarnWOH2O+zSSuMs8jQM/x7k 6tIOlwtRDVGw3VuvNbb4MJnLzdHRxq3qy6ueDYuhmhHslxjD1Cbr3eE1RA7Da9aX kNDgjfXtdah52HWUZbIIxHQYzyCg5G3M5yy51GhUlA2Fe1sbPpNcEBeyEDK/jH3Y +7G+tgR+CdMvSFraCiYKHa1drVPJHeqNvZAqPNHKxpKwOwOoJEYrsW4wb/mJ7ybe o8xNYK691hcaMvHqwI47tw4hZfrI0f0+gQKKzENQQk8/8yUZ/0jgMRlW/Cz0yYIa FZEg+OJ/yEs8vKfYerIN =Rfn4 -----END PGP SIGNATURE-----

3 2

stopping the censoring of tor users.
by blacklight . 26 Feb '16

26 Feb '16

hello there! i don't know if this mailing list works but i thought of giving it a try. i was lately reading an article ( http://www.pcworld.com/article/3037180/security/tor-users-increasingly-trea… ) and it was about tor users getting blocked from accessing alot of website. but after giving this some thought i think i came up with a possible solution to the problem :there is a thing called bridges, they are used to access the tor network without your isp knowing that you use tor, but if you can use those proxies to enter the network, it might also be possible to exit the network with them. But then we face a second challenge, the exit nodes have to be configured in such a way that it will relay traffic to such a bridge, so the exit node owners also need to know the ip of the bridge. While this doesn't seem difficult to do, it can become difficult. You see if the bridges are published on a public list(like normal bridges are) then the blocking sites in question will be able to block those address too. While this also posses a problem, a possible solution could be found in something called flashproxies, flashproxies are bridges with a really short life span, they are created and destroyed fairly swiftly, when this is done in a rapid pace, they become really hard to block because the ip changes all the time. So if the exit nodes can be configured to make use of such flash proxies, then the problem could be solved. I Must admit that not an expert on this or anything, and it needs alot of more thought, but it could work. so i was wondering if there are any experts who could help me with thinking out this subject and maybe confirm if this idea could work. greetings, blacklight

3 4

Fwd: Re: Support for mix integration research
by Sebastian G. <bastik.tor> 25 Feb '16

25 Feb '16

I'm forwarding this to the list, because it might contain relevant information. Mostly within George's reply. Initial reason to not send my reply to the list was to not bother too many people with seemingly irrelevant questions on my part. I agree with the reply given in the forwarded message. It has to be considered what 'it' does to the network. Best Regards, Sebastian G. (bastik) -------------- Forwarded Message -------------- Subject: Re: [tor-dev] Support for mix integration research Date: Thu, 25 Feb 2016 19:58:56 +0100 From: George Kadianakis <desnacked(a)riseup.net> To: Sebastian G. <bastik.tor> <bastik.tor(a)googlemail.com> "Sebastian G. <bastik.tor>" <bastik.tor(a)googlemail.com> writes: > 25.02.2016, 13:08 George Kadianakis: >> b) Does this increase the hard disk or memory requirement of people running Tor >> relays? That is in high-latency mode, will Tor relays need to store client's >> traffic for longer? How does that impact the memory and hard disk >> requirement of people running Tor relays? > > Hello, > > this has been intentionally sent off list. > > I just don't understand the question. How would you delay traffic > without storing it for longer? Whenever in memory or disk, the data that > are being delayed have to be stored somewhere, as far as I understand. > > Could one delay traffic on a wire? E.g. like with a truck that drives on > a road between two storage facilities where you couldn't say it is > already stored in the facilities. > > I fail to see how it would be possible to have a system that delays > something without holding back whatever is delayed. > I agree. I'm wondering how this increases the memory and hard disk requirement of running a relay. And how much would the current relays contribute to such a high-latency system? And how much memory / CPU will be required to contribute meaningfully to this. And what about DDoS opportunities? All these things will need to be thought of so that we don't overwhelm the current Tor network by introducing this high-latency mode. Because if that's the case, we should probably have a separate network for the high-latency mode. Pity you replied off list, this conversation is of sufficient interest. Cheers. > If you currently take in x and give out y at the same rate, what needs > to be stored is what has to be buffered. If now the rate of y decreases > while the rate for x remains the same, more stuff needs be buffered. > Unless you reduce the rate for x, more storage is required. > > Sorry, I just don't get it. Please show me where my error is. Can be > short. :) >

1 0

Fwd: Downloadable content: Fonts!
by Nathan Freitas 25 Feb '16

25 Feb '16

Mozilla is adding some new runtime installation features to reduce the size of the mobile Firefox APK. Is this happening at all on desktop? It makes me nervous as the "default" config could very much more greatly, not to mention having a new centralized attack channel. ----- Original message ----- From: Sebastian Kaspari <s.kaspari(a)gmail.com> To: "mobile-firefox-dev" <mobile-firefox-dev(a)mozilla.org> Subject: Downloadable content: Fonts! Date: Fri, 19 Feb 2016 11:56:42 +0000 Good news, everyone! Our first step to downloadable content has been enabled in Nightly: This means we now stopped to ship fonts[1] in the APK and instead download them at runtime (Bug 1194338 [2]). With that we reduced the size of the APK by roughly 6.4% (~ 2.7MB) [3]. Without having the fonts downloaded (yet) our users can still browse websites but they may look less nice. And in fact, as things go, a bug caused just that to happen in Nightly (We don't download any fonts): bug 1249354 [4]. So if websites are currently looking a bit weird on Nightly then that's because of that. The bug should be resolved soon and after that let me know if you see any new weird issues related to (wrong) fonts. :) Our plans for the future: * Right now we ship the list of fonts and the location to download with the application. We want to synchronize this catalog of content from a Kinto instance: https://bugzilla.mozilla.org/show_bug.cgi?id=1201059 * We want to download hyphenation dictionaries at runtime too: https://bugzilla.mozilla.org/show_bug.cgi?id=1095719 * Eventually we might even want to download (some) localization files at runtime: https://bugzilla.mozilla.org/show_bug.cgi?id=945123 Best, Sebastian [1] https://www.youtube.com/watch?v=6J2rrFiN1Jw [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1194338 [3] https://twitter.com/Anti_Hype/status/699905577196134400 [4] https://bugzilla.mozilla.org/show_bug.cgi?id=1249354 _______________________________________________ mobile-firefox-dev mailing list mobile-firefox-dev(a)mozilla.org https://mail.mozilla.org/listinfo/mobile-firefox-dev

5 7

Tor Consensus Transparency, take two
by Linus Nordberg 25 Feb '16

25 Feb '16

Hi, Some time ago, like 1,5 years, this list received a proposal for how to build Tor Consensus Transparency. I got some good feedback and then i got busy with other things. Here's an updated version with feedback incorporated, change in wordings, more of an actual specification, some changes in data structures and over all an easier read, I hope. I'll follow up shortly with a separate email describing the status of an experimental implementation. --8<---------------cut here---------------start------------->8--- Filename: xxx-tor-consensus-transparency.txt Title: Tor Consensus Transparency Author: Linus Nordberg Created: 2014-06-28 Status: Draft 0. Introduction This document describes how to provide and use public, append-only, verifiable logs containing Tor consensus and vote status documents, much like what Certificate Transparency [CT] does for TLS certificates, making it possible for log monitors to detect false consensuses and votes. Tor clients and relays can refuse using a consensus not present in a set of logs of their choosing, as well as provide possible evidence of misissuance by submitting such a consensus to any number of logs. 1. Overview Tor status documents, consensuses as well as votes, are stored in one or more public, append-only, externally verifiable log using a history tree like the one described in [CrosbyWallach]. Consensus-users, i.e. Tor clients and relays, expect to receive one or more "proof of inclusions" with new consensus documents. A proof of inclusion is a hash sum representing the tree head of a log, signed by the logs private key, and an audit path listing the nodes in the tree needed to recreate the tree head. Consensus-users are configured to use one or more logs by listing a log address and a public key for each log. This is enough for verifying that a given consensus document is present in a given log. Submission of status documents to a log can be done by anyone with an internet connection (and the Tor network, in case of logs only on a .onion address). The submitter gets a signed tree head and a proof of inclusion in return. Directory authorities are expected to submit to one or more logs and include the proofs when serving consensus documents. Directory caches and consensus-users receiving a consensus not including a proof of inclusion may submit the document and use the proof they receive in return. Auditing log behaviour and monitoring the contents of logs is performed in cooperation between the Tor network and external services. Relays act as log auditors with help from Tor clients gossiping about what they see. Directory authorities are good candidates for monitoring log content since they know what votes they have sent and received as well as what consensus documents they have issued. Anybody can run both an auditor and a monitor though, which is an important property of the proposed system. 2. Motivation Popping a handful of boxes (currently five) or factoring the same number of RSA keys should not be ruled out as a possible attack against a subset of Tor users. An attacker controlling a majority of the directory authorities signing keys can, using man-in-the-middle or man-on-the-side attacks, serve consensus documents listing relays under their control. If mounted on a small subset of Tor users on the internet, the chance of detection is probably low. Implementation of this proposal increases the cost for such an attack by raising the chances of it being detected. Note that while the proposed solution gives each individual some degree of protection against using a false consensus this is not the primary goal but more of a nice side effect. The primary goal is to detect correctly signed consensus documents which differ from the consensus of the directory authoritites. This raises the risk of exposure of an attacker capable of producing a consensus and feed it to users. The complexity of the proposed solution is motivated by the fact that the log key is not just another key on top of the directory authority keys since the log doesn't have to be trusted. Another value is the decentralisation given -- anybody can run their own log and use it. Anybody can audit all existing logs and verify their correct behaviour. This empowers people outside the group of Tor directory authority operators and the people who trust them for one reason or the other. 3. Design Communication with logs is done over HTTP using TLS or Tor onion services for transport, similar to what is defined in [rfc6962-bis-12]. Parameters for POSTs and all responses are encoded as name/value pairs in JSON objects [RFC4627]. Summary of proposed changes to Tor: - Configuration is added for listing known logs and for describing policy for using them. - Directory authorities start submitting newly created consensuses to at least one public log. - Tor clients and relays receiving a consensus not accompanied by a proof of inclusion start submitting that consensus to at least one public log. - Consensus-users start rejecting consensuses accompanied by an invalid proof of inclusion. - A new cell type LOG_STH is defined, for clients and relays to exchange information about seen tree heads and their validity. - Consensus-users send seen tree heads to relays acting as log auditors. - Relays acting as log auditors validate tree heads (section 3.2.2) received from consensus-users and send results back. - Consensus-users start rejecting consensuses for which valid proofs of inclusion can not be obtained. Definitions: - Log id: The SHA-256 hash of the log's public key, to be treated as an opaque byte string identifying the log. 3.1. Consensus submission Logs accept consensus submissions from anyone as long as the consensus is signed by a majority of the Tor directory authorities of the Tor network that it's logging. Consensus documents are POST:ed to a well-known URL as defined in section 5.2. The output is what we call a proof of inclusion. 3.2. Verification 3.2.1. Log entry membership verification Calculate a tree head from the hash of the received consensus and the audit path in the accompanying proof. Verify that the calculated tree head is identical to the tree head in the proof. This can easily be done by consensus-users for each received consensus. We now know that the consensus is part of a tree which the log claims to be The Tree. Whether this tree is the same tree that everybody else see is unknown at this point. 3.2.2. Log consistency verification Ask the log for a consistency proof between the tree head to verify and a previously known good tree head from the pool. Section 5.3 specifies how to fetch a consistency proof. [[TBD require auditors to fetch and store the tree head for the empty tree as part of bootstrapping, in order to avoid the case where there's no older tree to verify against?]] [[TODO description of verification of consistency goes here]] Relays acting as auditors cache results to minimise calculations and communication with log servers. [[TBD have clients verify consistency as well? NOTE: we still want relays to see tree heads in order to catch a lying log (the split-view attack)]] We now know that the verified tree is a superset of a known good tree. 3.3. Log auditing A log auditor verifies two things: - A logs append-only property, i.e. that no entries once accepted by a log are ever altered or removed. - That a log presents the same view to all of its users [[TODO describe the Tor networks role in auditing more than what's found in section 3.2.2]] A log auditor typically doesn't care about the contents of the log entries, other than calculating their hash sums for auditing purposes. Tor relays should act as log auditors. 3.4. Log monitoring A log monitor downloads and investigates each entry in a log searching for anomalies according to its monitoring policy. This document doesn't define monitoring policies but does outline a few strategies for monitoring in section [[TBD]]. Note that there can be more than one valid consensus documents for a given point in time. One reason for this is that the number of signatures can differ due to consensus voting timing details. [[TODO Are there more reasons?]] [[TODO expand on monitoring strategies -- even if this is not part of the proposed extensions to the Tor network it's good for understanding. a) dirauths can verify consensus documents byte for byte; b) anyone can look for diffs larger than D per time T, where "diffs" certainly can be smarter than a plain text diff]] 3.5. Consensus-user behaviour [[TODO move most of this to section 5]] Keep an on-disk cache of consensus documents. Mark them as being in one of three states: LOG_STATE_UNKNOWN -- don't know whether it's present in enough logs or not LOG_STATE_LOGGED -- have seen good proof(s) of inclusion LOG_STATE_LOGGED_GOOD -- confident about the tree head representing a good tree Newly arrived consensus documents start in UNKNOWN or LOGGED depending on whether they are accompanied by enough proofs or not. There are two possible state transitions: - UNKNOWN --> LOGGED: When enough correctly verifying proofs of inclusion (section 3.2.1) have been seen. The number of good proofs required is a policy setting in the configuration of the consensus-user. - LOGGED --> LOGGED_GOOD: When the tree head in enough of the inclusion proofs have been verified (section 3.2.2) or enough LOG_STH cells vouching for the same tree heads have been seen. The number of verifications required is a policy setting in the configuration of the consensus-user. Consensuses in state UNKNOWN are not used but are instead submitted to one or more logs. If the submission succeeds, this will take the consensus to state LOGGED. Consensuses in state LOGGED are used despite not being fully verified with regard to logging. LOG_STH cells containing tree heads from received proofs are being sent to relays for verification. Clients send to all relays that they have a circuit to, i.e. their guard relay(s). Relays send to three random relays that they have a circuit to. 3.6. Relay behaviour when acting as an auditor In order to verify the append-only property of a log, relays acting as log auditors verify the consistency of tree heads received in LOG_STH cells. An auditor keeps a copy of 2+N known good tree heads in a pool stored on persistent media [[TBD where N is either a fixed number in the range 32-128 or is a function of the log size]]. Two of them are the oldest and newest tree heads seen, respectively. The rest, N, are randomly chosen from the tree heads seen. [[TODO describe or refer to an algorithm for "randomly chosen", hopefully not subjective to flushing attacks (or other attacks)]]. 3.7. Notable differences from Certificate Transparency - The data logged is "strictly time-stamped", i.e. ordered. - Much shorter lifetime of logged data -- a day rather than a year. Is the effects of this difference of importance only for "one-shot attacks"? - Directory authorities have consensus about what they're signing -- there are no "web sites knowing better". - Submitters are not in the same hurry as CA:s and can wait minutes rather than seconds for a proof of inclusion. 4. Security implications TODO 5. Specification 5.0. Data structures Data structures are defined as described in [RFC5246] section 4, i.e. TLS 1.2 presentation language. While it is tempting to try to avoid yet another format, the cost of redefining the data structures in [rfc6962-bis-12] outweighs this consideration. The burden of redefining, reimplementing and testing is extra true for those structures which need precise definitions because they are to be signed. 5.1. Signed Tree Head (STH) An STH is a TransItem structure of type "signed_tree_head" as defined in [rfc6962-bis-12] section 5.8. 5.2. Submitting a consensus document to a log POST https://<log server>/tct/v1/add-consensus Input: consensus: A consensus status document as defined in [dir-spec] section 3.4.1 [[TBD gziped and base64 encoded to save 50%?]] Output: sth: A signed tree head as defined in section 5.1 refering to a tree in which the submitted document is included. inclusion: An inclusion proof as specified for the "inclusion" output in [rfc6962-bis-12] section 6.5. 5.3. Getting a consistency proof from a log GET https://<log server>/tct/v1/get-sth-consistency Input and output as specified in [rfc6962-bis-12] section 6.4. 5.x. LOG_STH cells A LOG_STH cell is a variable-length cell with the following fields: TBDname [TBD octets] TBDname [TBD octets] TBDname [TBD octets] 6. Compatibility TBD 7. Implementation TBD 8. Performance and scalability notes TBD A. Open issues / TODOs - TODO: Add SCTs from CT, at least as a practical "cookie" (i.e. no need to send them around or include them anywhere). Logs should be given more time for distributing than we're willing to wait on an HTTP response for. - TODO: explain why no hash function and signing algorithm agility, [[rfc6962-bis-12] section 10 - TODO: add a blurb about the values of publishing logs as onion services - TODO: discuss compromise of log keys B. Acknowledgements This proposal leans heavily on [rfc6962-bis-12]. Some definitions are copied verbatim from that document. Valuable feedback has been received from Ben Laurie, Karsten Loesing and Ximin Luo. C. References [CrosbyWallach] http://static.usenix.org/event/sec09/tech/full_papers/crosby.pdf [dir-spec] https://gitweb.torproject.org/torspec.git/blob/HEAD:/dir-spec.txt [RFC4627] https://tools.ietf.org/html/rfc4627 [rfc6962-bis-12] https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/12 [CT] https://https://www.certificate-transparency.org/ --8<---------------cut here---------------end--------------->8---

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev February 2016