Re: [tor-talk] Tor no longer works with win2K ??
On 2011-11-10 11:39 , Anon Mus wrote: [..] Nov 10 10:17:10.093 [Warning] Warning from libevent: evsig_init: socketpair: Cannot assign requested address [WSAEADDRNOTAVAIL ] This is the important part, it states that the address is not available. Did your properly shutdown the old version? And/or did you maybe put a listening address in your configuration? Check C:\Documents and Settings\Administrator.WARMACHINE\Application Data\Vidalia\torrc for the latter. My vidalia is 0.2.10 which works fine.. Are there any solutions ? Or is Win2K no longer being supported by? , if so the tor sites download page should be changed to reflect that Windows 2000 was EOL'd by Microsoft last year, but I don't see why newer binaries would not work as TCP/IP is still TCP/IP :) Greets, Jeroen ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Tor no longer works with win2K ??
On 2011-11-10 13:13 , Anon Mus wrote: [..] I do have a socks listen address specified SocksListenAddress 127.0.0.1 Unless a SOCKS capable program is listening there already, it should not be an issue. See 'netstat -an' in a command prompt to check if this is the case or not. Greets, Jeroen ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Fwd: Anonymous to attacks Hidden Wiki and othershiddenservice
On 2011-10-24 13:34 , hi...@safe-mail.net wrote: [..] The problem is that they're using denial of service attacks to overload the servers, and parts of the Tor network as a result. Tor doesn't seem to handle this very well. The internet does not handle (D)DoS attacks either. This takes down hidden services and nodes, consequently censors Tor hidden services and makes several circuits halt. If that isn't an attack on Tor, then I'm a fish with wings. Wow, you are a fish with wings and you can even write emails ;) DoS attacks by overloading a network are always possible and the only real solution to that is to add way more capacity than the adversary has. As with Tor there is no way to identify the source node, implementing a rate limit on source is impossible. Doing rate limiting on the intermediate nodes would just cause a network-wide ratelimit and also impeed other traffic. And if it was a proper DDoS attack you would run out of filtering resources before you ran out of capacity. In other words: not much you can do about it but add more nodes with more capacity. Greets, Jeroen ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
[tor-talk] Avoiding DoS inside the Tor network (Was: Anonymous to attacks Hidden Wiki and othershiddenservice)
On 2011-10-24 14:10 , Eugen Leitl wrote: On Mon, Oct 24, 2011 at 01:46:13PM +0200, Jeroen Massar wrote: On 2011-10-24 13:34 , hi...@safe-mail.net wrote: [..] The problem is that they're using denial of service attacks to overload the servers, and parts of the Tor network as a result. Tor doesn't seem to handle this very well. The internet does not handle (D)DoS attacks either. Don't know what the internet is, but if you speak BGP on the Internet you can always nullroute the target, or the origin network. (I mentioned in my mail that one cannot do that for Tor, implying one can with the normal internet, because of the absence of a source address, should have written that out better I guess) Even those nice nullroute communities do not make those packets arrive at your upstream links and fill them up. Only way to do that is then to simply stop announcing the route in question to the links that those packets are coming in over. (this is the strategy taken by most IRC servers btw, which then keep on announcing the prefix on the local IX where most of their clients likely exist) Do also note that is a generally a limit to the amount of source filtering one can do. Every ACL added can bog things up and one really does not want to keep state. But it all depends on the attack, in the end more have more capacity is the only really thing one can do about this. [..] DoS attacks by overloading a network are always possible and the only real solution to that is to add way more capacity than the adversary has. That's the brute force way to do it. Smarter ways would be use connectionless protocols... Unfortunately Tor implies (TCP + TLS/SSL) connections and thus lots of state. Thus wiping out a node would just mean creating enough connections which should be easily done on most nodes in the directory given a properly sized botnet. ... or use proof of work (like hashcash) in order that using the network at high priority needs credits which have to be earned by being a member in good standing (as seen from other nodes). If you would introduce something like hashcash, does the source node or the intermediate node have to do this hashcash calculation? I do hope that verifying the hashcash is then factors lighter than generating it. Do note though that some If the source has to do it you are going to transfer a bit of text from the source to the intermediary node and thus the intermediary node might learn that way what the real source is. I don't think this is very viable, even though it has merit, I would say, change the subject line and go for a proposal and we'll see how far it can solve something. Greets, Jeroen ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Avoiding DoS inside the Tor network (Was: Anonymous to attacks Hidden Wiki and othershiddenservice)
On 2011-10-24 15:29 , Eugen Leitl wrote: On Mon, Oct 24, 2011 at 02:40:26PM +0200, Jeroen Massar wrote: If you would introduce something like hashcash, does the source node or the intermediate node have to do this hashcash calculation? Like in BitCoin, only at minting stage would you need to generate payment tokens. In fact, the tokens could be generated by Tor developers themselves as we implictly trust them when we verify the signed code on official released packages. This would do at least initially. That would also require them to distribute those coins and to first of all mint them. How does one distribute those coins? That is, how do you know how much to give to a certain user? The nice thing about bitcoin is that the minting is done by the user, if you can mint a lot then you can use a lot. The problem would be with overhead of network tracking transactions to prevent double spending. That would be probably prohibitive, as currently BTC tranactions take some time to clear. It's probably a stupid idea. There is no such thing as a stupid idea, there are ideas though that don't apply all too well to the situation ;) I think it is interesting but quite infeasible to do this. I do hope that verifying the hashcash is then factors lighter than generating it. Do note though that some Verifying is easy, preventing double spending without centralism is hard. And to be able to verify you don't only need a centralized mechanism, but you would also need to setup a connection to that location to be able to verify that you can setup a connection, which would need a ... ;) Also, people sometimes already complain that Tor is slow, this won't help with that too much. Note that if one does this payment thing, will that pay for a single hop or for the full circuit? How would one crypt that payment thus avoiding the node steal it and pay it's own traffic with it? On the Internet one also only pays their direct peers, thus for the Tor/Bitcoin model one would then best be off only paying the direct peers and the peer could then use that bitcoin to pay the link to the next hop. If the source has to do it you are going to transfer a bit of text from the source to the intermediary node and thus the intermediary node might learn that way what the real source is. The idea is that you have to spend some tokens if you want to push a lot of data (or else there would be backpressure/throttling), which you would have to earn by being a good relay or exit. If you ratelimit regular streams then that could mean that the regulars who never pay are thus flooded and the others are easily identified as they add a payment token (which need to be per-hop). Greets, Jeroen ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] GeoIP
On 2011-10-22 09:27 , kamyar kamyar wrote: Hi all, What's GeoIP file in TOR directory? what's it used for? The file contains IPv4 address ranges to Country mappings. It is used for determining the country that an IP address is in. This as several configuration commands allow avoiding/requesting a specific country. (Yes, these kind of mappings are not 100% accurate and due to the dynamics of the Internet might be wrong too, but it is 'good enough') what are the numbers beside each line inside the file?related to fingerprints? The numbers decimal representations of an IP address. From the comment above src/or/geoip.c's geop_load_file(): [..] * Recognized line formats are: * INTIPLOW,INTIPHIGH,CC * and * INTIPLOW,INTIPHIGH,CC,CC3,COUNTRY NAME * where INTIPLOW and INTIPHIGH are IPv4 addresses encoded as 4-byte unsigned * integers, and CC is a country code. [..] Thus for instance 123.45.67.0 becomes: $ printf %02x %02x %02x %02x\n 123 45 67 0 7b 2d 43 00 Thus 0x7b2d4300 which is in decimal: $ printf %d\n 0x7b2d4300 2066563840 Thus to convert them back: $ printf %x\n 2066563840 7b2d4300 $ printf %d.%d.%d.%d\n 0x7b 0x2d 0x43 0x00 123.45.67.0 That is, if you actually wanted to look inside them ;) Greets, Jeroen ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Strange TOR connection behavior? EntryNodes/Strict
On 2011-10-17 12:24 , fati...@safe-mail.net wrote: I'm a little new to TOR. I run it in linux and start and stop it from a terminal window. I have changed my torrc to include the following: EntryNodes poohbear where 'poohbear' is the entry node I wish to use. This setup works, however when I monitor the traffic with wireshark, I see that tor is making many https connections to other tor nodes prior to establishing a secure connection with the poohbear node. Those are likely the fetches for the Tor Directory data which is effectively a list of all Tor nodes in the network, thus the also how to reach your poohbear node etc. Why is this the case? Shouldn't the EntryNodes operator limit connections to the poobear node, and only the poohbear node? For the rest of your connections it should. Greets, Jeroen ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] German police keylogger analysis (and the effects on Tor are....?)
On 2011-10-13 13:40 , and...@torproject.org wrote: On Wed, Oct 12, 2011 at 11:39:12PM -0700, williamwright...@yahoo.com wrote 1.1K bytes in 24 lines about: : Keyloggers would, I assume, defeat the whole purpose of Tor since the URL would be recorded and sent to the fedz. If you lose control over your local computer, tor cannot help you. If the attacker can see every keystroke you enter, you've lost. I'm not sure if this is true for onscreen keyboards as well. If the adversary is taking a video or a high enough rate of screenshots then they should be able to catch what keys are being pressed, it does make it a bit harder. As you said though, if you are locally attacked, you already lost. But like always, just depends on what you are protecting against. If the German customs agents took your computer away from you at a border, you should assume the worst case and no longer trust your OS nor hardware. It's possible tails may help here, but depending upon hardware vs. software (bios firmware) attacks, the computer may not be trustworthy at all. If the bios is infected, tails cannot help. Traveling with throw-away hardware is therefor always a good idea if you want to keep your stuff secure. The US also has the nasty policy of effectively placing you in a no-law-zone before immigration. Again, all depends on what one is protecting against and how paranoid one is ;) Greets, Jeroen ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] PSI Jabber leaking the client hostname?
On 2011-10-12 14:14 , phil...@bailey.st wrote: [..] Opened session for test2@x.onion/foobar I guess is not normal to have your hostname going to some tor end point, is this leak related to PSI or maybe some other misconfiguration. That 'foobar' portion (or the long number in the other session you had) is called the 'XMPP resource'. Generally this is custom definable. In PSI you can change this under Menu General - Account Setup - select the account, hit Modify = Misc Then unselect the Use hostname as a resource option and enter something gibberish. In XMPP this 'resource', along with it's priority, allows message routing to work when one is logged in multiple times. Greets, Jeroen ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] WSJ- Google- Sonic Mr. Applebaum
On 2011-10-11 10:07 , Eugen Leitl wrote: On Mon, Oct 10, 2011 at 11:20:05PM +0200, Jeroen Massar wrote: Use your own servers at the co-lo. Use TPM and tamper-proof systems. Does not matter, given enough power/money/force your adversary can walk Au contraire, it does matter very much in practice. By controlling your hardware instead of relying on vendors or even teh cloud you're raising the bar for attacks considerably. Consider that nobody can know which exactly security measures you've taken. Of course you are raising the bar, but that is the only thing you are doing, as the adversary can still walk in, be that with a warrant making it legal, or just by going in. Criminals don't ask for your Ok. into that colo and use vampire taps to replug (both power and network) Did you catch the part with the video, also streamed off-site? How exactly does that matter? It will already be too late and your full hardware will be off site in a location that you don't control, still running fully and no way for you to stop them from doing what they want to do with it, be that freeze the memory or any component needed. Or do you watch that video screen 24/7 like in the movies with the guards on duty being shown a replay? :) Yes, nice things like mercury switches, glueing the whole thing together and other such tricks can even deny physical access, but really, what are you trying to protect there? :) If there's a convenient temporal lacune on multiple probes, you know your hardware is no longer trusted. I am surprised if you are that paranoid that you trust the hardware in the first place. You do realize where the designs come from and where they are built right? :) Yes, you will know that your hardware from that point is untrusted, but who says it was not before? your box without you noticing anything and monitor the rest from there on. They are welcome to tap the network. It's what they already can do, by mirroring the incoming switch port and packet capturing there. This is not relevant to accessing secrets locked in hardware, or present at runtime. Nope, but that is why a vampire tap can also do power, so they can remove the box from the rack/location that you have as 'secure' and then they can do whatever time consuming things you want. Unless you have a full remote kill switch in there packed with some C4 or so. But that is why I mention rubberhose: if they want to get the info in there, they will politely ask you for them instead. As for TPM, who build that piece of hardware and are you sure that a copy of your keys are not kept elsewhere? Because you generated the key itself, of course, and using a physically secured TPM token you installed yourself. Did you build that TPM token? I am just trying to give obvious hints here and above etc... For that matter, did you write and audit 100% of the code, oh and not to forget the compiler that you are using for that code? And what about that little video camera just behind your screen, did you notice it already? ;) Like everything in live, it just depends on how much you care. For most people though, unless you are doing super secret evil stuff, just using a Gmail account with PGP in combo with SMTP/IMAP is good enough(tm) a security measure. It can be rather hard to access a piece of hardware hotglued into an internal USB port, with hardware with live IPMI monitoring, including chassis intrusion detection, including motion-detected streaming video streaming to cryptographically secured local filesystem and also off-site. Local filesystem does not matter, as you won't see it. Thus if the video cuts, the only lesson you learned is that the box is not to be trusted anymore, but then it is already too late in most cases as they also likely know who is footing the bill, just follow the money and thus where your bed lives. It is all doable, but it won't be done in practice or ordinary threat models. I used to store crypto secrets on USB smartcards, and have streaming video in the rack, all on UPS. Nowadays, it's even easier. No point to make it too easy. Mallory should earn his keep. At one point or another they just apply rubberhose crypto thus don't make it too difficult. Why do you bother breathing? You'll die, anyway. I don't have to bother breathing, not everybody is Darth Vader, it happens automatically more or less as a reflex for most people and there is so much fun in the world without having to consider conspiracy theories ;) Greets, Jeroen ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] WSJ- Google- Sonic Mr. Applebaum
On 2011-10-11 13:48 , Julian Yon wrote: On 11/10/11 09:07, Eugen Leitl wrote: At one point or another they just apply rubberhose crypto thus don't make it too difficult. Why do you bother breathing? You'll die, anyway. I think you missed the point Jeroen was making there. If Mallory *really* wants to compromise your server, there will be a level of security beyond which a gun to your children's heads is the most cost-effective attack. In most people's threat models, they'd rather take their chances with compromised data than with their kids' lives. In such a model, making the server too secure can itself be a risk. That describes my point perfectly, thanks! Greets, Jeroen ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] WSJ- Google- Sonic Mr. Applebaum
On 2011-10-11 13:18 , Moritz Bartl wrote: On 10.10.2011 23:20, Jeroen Massar wrote: Does not matter what service you use, they all fail under the pressure Use your own servers at the co-lo. Use TPM and tamper-proof systems. Does not matter, given enough power/money/force your adversary can walk into that colo and use vampire taps to replug (both power and network) your box without you noticing anything and monitor the rest from there on. If the box is at a place under your control, you will at least know. Replugging can be noticed (packet drops, changes in voltage) and the system can be shut down/wiped. Google for Vampire Taps. You won't notice a thing unless you have very very sensitive voltage etc measurements happening. BTW, I want to set up a scalable mail server like that, so if anyone has useful input, please let me know. Like everything else (eg how many locks you have on your house), it all depends completely who your adversary is and how much protection you require against it. In the end it will come down to a delay for the adversary and annoyance on your part with the problem that if the adversary wants your information hard enough they will 'nicely' ask. Greets, Jeroen ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] WSJ- Google- Sonic Mr. Applebaum
On 2011-10-11 16:42 , Eugen Leitl wrote: On Tue, Oct 11, 2011 at 12:48:53PM +0100, Julian Yon wrote: I think you missed the point Jeroen was making there. If Mallory *really* wants to compromise your server, there will be a level of security beyond which a gun to your children's heads is the most I think he missed my point: there is a wide spread in threat scenarios and capabilities. We actually fully agree with that and it is also what I am writing. Though with the added point that the deeper you dig yourself in, the quicker your adversary might just use the mighty rubber hose technique instead to get to your so dearly protected secrets, depends all on your adversary of course and how valuable that data is for them and you. What we care most is preventing easy, undetectable and hence scalable information vacuuming by way of forcing cloud operators to provide convenient access APIs. This is what dominates the volume. Thus your threat model involves not trusting any service where software is running of an external organization. Though as stated before, I do really hope you verify 100% of your code, including the compiler, not forgetting about the microcode in CPUs According to the above statement having a box in a co-lo thus is mostly fine unless you don't trust the hardware that is. Why are you then arguing for live video streams and glueing everything tight? Then again, if you think you need to do all of that, go ahead. None such are available at the co-lo hosting own hardware or freedom boxes on home broadband. Sure Shabak ninjas could abseil through the skylights, garotte the cat and compromise my NIC, but if I'm worried about these I shouldn't be relying on Tor, anyway. Speaking of that NIC, ever wondered how much code runs inside that PHY in there? :) *wink* cost-effective attack. In most people's threat models, they'd rather take their chances with compromised data than with their kids' lives. In such a model, making the server too secure can itself be a risk. This is not the threat model we're looking for. Move along. Of course that is not the one you or anyone else wants as it will inflict personal injury. Fortunately it tends to be the last resort and you must have pissed off the adversary first before they take this step. Greets, Jeroen ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Securing servers
On 2011-10-11 15:39 , Moritz Bartl wrote: Hi Jeroen, I find this is an interesting discussion, although it feels very much off topic. Is there another list to discuss this? No idea about the proper venue. I am sure that if it becomes to annoying one Tor Project member or another will kick the persons involved and nicely ask to move along somewhere else. On 11.10.2011 14:33, Jeroen Massar wrote: If the box is at a place under your control, you will at least know. Replugging can be noticed (packet drops, changes in voltage) and the system can be shut down/wiped. Google for Vampire Taps. You won't notice a thing unless you have very very sensitive voltage etc measurements happening. How are you going to Vampire Tap a simple Wiimote built inside the server, or other devices of that kind? Or lock the server to the building (and detect movement of the lock). As I stated, if you have sensitive measurements then you can detect this. What you then do upon this detection is a different thing. Like everything else (eg how many locks you have on your house), it all depends completely who your adversary is and how much protection you require against it. It makes a lot of difference if you *know* about access to sensitive data or not. I have not stated to disagree with that did I? :) As a side-step: The server being (software) hacked is IMHO way more probable then somebody getting physical access to it. Thus having a disposable key that allows reading of data that is stored also means that if that process is hacked that they have full access to the key, no sensor protects. Back to the original message: The prime point at the start of the thread was that it is completely unsafe to use a service like gmail for storing email. IMHO one can 'safely' use those kind of service up to a certain level given that you either don't use it for communications you don't care that they are leaked or if you do care about that that people sending email to it use PGP so that only sender/receiver is disclosed when they do get access to that store. (assuming adversary is unable to crack your PGP crypto of course ;) That's also the difference of a data center run by friends who will let you know with a certain probability, and some corporate DC where you will most likely never find out that something is bugged. That is more a trust issue. If someone has access to it, you better know it before they can do anything with it. Also Corporate datacenters have the tendency of allowing stuff to be lost in the noise ;) Greets, Jeroen ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] WSJ- Google- Sonic Mr. Applebaum
On 2011-10-11 17:29 , Eugen Leitl wrote: On Tue, Oct 11, 2011 at 02:30:01PM +0200, Jeroen Massar wrote: Of course you are raising the bar, That's the main idea. but that is the only thing you are doing, as the adversary can still walk in, be that with a warrant making If they have to dispatch a warm body to a remote physical location my job is done already. If it has to be a warm sentient body who has to analyze an unfamiliar situation and attempt an undetected physical layer attack I've already succeeded wildly beyond all expectations. I fully agree, it is all about delay and cost. From that perspective the cheapest way in is to send that not so sentient warm body directly to you though. But we are running in circles here don't you think ;) [..] How exactly does that matter? It will already be too late and your full [..] hardware will be off site in a location that you don't control, still Do you see the difference between Gmail or Amazon cloud rendering upon Caesar what is his and my logless postfix running on you own hardened box, with mail residing client-side on a crypto filesystem? The only difference is that for your hardened box it is way more expensive (your hardware+hosting costs money and gmail costs nothing), very noticeable as being 'special' as you likely don't share it too much with others and especially not the 'sheep' that are so good to hide traffic in. Yes, your setup will be way more secure, but at which cost and to protect exactly what? The original thread threat point was about 'is gmail safe for email', where my point was 'if you do GPG then they can only see the src/dst email address' (and obviously other SMTP headers). Your threat point seems to be to safeguard every single bit at a very high price, while that is completely valid, that is not for everybody though. running fully and no way for you to stop them from doing what they want to do with it, be that freeze the memory or any component needed. Do you have the slightest idea how much that would cost, especially if I'm not to notice? The fact that you will have such a hardened box is already easily noticeable and it will cost you a lot too. The gmail + PGP setup is free, and if they compromise one, well, just set setup a new one. Heck, jump to Yahoo or GMX or every other one. Or do you watch that video screen 24/7 like in the movies with the guards on duty being shown a replay? :) My thinking is that I wouldn't hire you as a security consultant. You are clearly thinking of hiring one, I guess you need one too. Note that I am not a security consultant in any way, thus I can't help you with even if you wanted me to. If there's a convenient temporal lacune on multiple probes, you know your hardware is no longer trusted. I am surprised if you are that paranoid that you trust the hardware in You seem to have poor reading comprehension and security analysis skills. Ever considered that you are the one who diverted completely from the original subject? ;) I'll skip over the even more silly bits which have no technical merit at all. [..] They are welcome to tap the network. It's what they already can do, by mirroring the incoming switch port and packet capturing there. This is not relevant to accessing secrets locked in hardware, or present at runtime. Nope, but that is why a vampire tap can also do power, so they can remove the box from the rack/location that you have as 'secure' and then My boxes are already on an UPS. And then there is a cable between the UPS and your hardened box, that cable can be clamped too. Or did you cement that all in? :) That's the whole point, or provider can simply cut power, and simulate an outage. The point is that they would have to physically approach the rack, at which point there will be a triggered recording. You have no idea where the recording goes and which out of band channels it might use. If you're smart, you'll back off when you see the LED glow. If you can see NIR, I mean. Must be an awesome datacenter that nobody ever approaches that rack of yours. We can play this game ten times to Sunday, and I can assure you that with a minimal amount of planning you can make the traceless extraction of tamper-proof hosted secrets arbitrarily difficult. Difficult and very expensive. I don't think that is what people who just want to have a bit of privacy for their email want to go all the way for. they can do whatever time consuming things you want. Unless you have a full remote kill switch in there packed with some C4 or so. It's lead azide, actually. I see you've been reading my stolen design documents. Every 10 year old who watched a silly movie can come up with that one. [..] Did you build that TPM token? I am just trying to give obvious hints here and above etc... You're being out ouf your depth and not realizing it. Right back at ya! ;) [..] For most people though, unless you are doing
Re: [tor-talk] Securing servers
On 2011-10-11 20:24 , t...@lists.grepular.com wrote: [..] I've been doing this myself for a while now. I wrote/released some software to do it. It's described here: https://grepular.com/Automatically_Encrypting_all_Incoming_Email And here: https://grepular.com/Automatically_Encrypting_all_Incoming_Email_Part_2 Yes, that is an awesome method for very cheaply keeping your emails safe from prying eyes. (though unless one has an external server polling the mail and saving it again, it is not applicable to gmail, especially as one does not know how much data gmail and other such services retain as they don't guarantee deletion). The big advantage is also that there is no keying material that can cause the mails to be read, unlike most 'crypto filesystems' which tend to keep the crypto keys in memory for both reading and writing to the filesystem, thus if somebody is able to hack a process that can write (your incoming mailer) they can generally also read those files. The only missing component in the above puzzle is then to mirror new mails asap to a set of other hosts to act as a backup, just forwarding them to the other boxes with a rewrite can solve that though. Greets, Jeroen ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Inter-op connectivity of TOR directory authorities for the establishment of Private TOR Network
On 2011-10-11 19:14 , Faisal Rehman wrote: *Dear All,* As I am working to establish a small tor private network and for this purpose I have to and done the following things: 1. Configuration of Several Directory Authorities (Completed) 2. Inter-op connectivity of these authorities for the establishment of TOR Network (Pending) 3. Testing the Private TOR Network (Pending) Now I have to do the 2nd and 3rd step, so any help would be highly appreciated. You might want to check out the privnet portion of tor-utils: https://gitweb.torproject.org/sebastian/tor-utils.git That can set that all up very quickly. Though, that is a virtual network on the same host, one can copy the configs to other boxes and bootstrap your private network that way. Greets, Jeroen ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Securing servers
On 2011-10-11 21:04 , t...@lists.grepular.com wrote: On 11/10/11 19:34, Jeroen Massar wrote: [..] Regarding your comments on keys being stored in RAM on crypto filesystems, I have a working solution for that too. My Ubuntu laptop uses full disk encryption, but the key is shifted from RAM into the debug registers of the CPU as soon as it starts booting, and all crypto operations are performed directly on the CPU without the key being transferred back into RAM, using the CPU's AES-NI instructions. While that indeed solves (at least makes it really hard to get to it ;) the problem of they keys in memory/cpu-regs, it, at least from what I can see now, does not solve the problem that if a process which is allowed to do read/write operations on your fully encrypted disk to read that data when somebody has compromised that process. One thing to keep in mind. Your mail-directly-PGPd setup does not have that problem. This prevents the key being exposed during cold boot attacks. To achieve this, I patched my kernel using something called TRESOR. For more info see: https://grepular.com/Protecting_a_Laptop_from_Simple_and_Sophisticated_Attacks Gotta love the part about diving with a USB stick, now I just have to get one of those to try out if it survives at least 50m ;) But why don't you then just use only that USB stick instead of the SSD? Though of course the SSD is quite a bit faster, they have 16GB 3.0 editions and 64GB USB2 versions which should mostly be sufficient and half the space of the SSD in the box. [..] Another possibility would be to have a mail server as a hidden service, and then just set up the Internet facing server to immediately forward all incoming email to the hidden server via Tor. And presto, everything is safe. And in a similar way one could setup a Gmail account and have a hidden service use the Tor network to exit to gmail and poll it over IMAP to fetch the email, find the mail store then ;) Greets, Jeroen ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] WSJ- Google- Sonic Mr. Applebaum
On 2011-10-10 22:27 , Eugen Leitl wrote: On Mon, Oct 10, 2011 at 07:07:35PM +0200, Jeroen Massar wrote: On 2011-10-10 18:42 , Andre Risling wrote: Here's how Google is a compliant slave. You still use Gmail?! Does not matter what service you use, they all fail under the pressure Use your own servers at the co-lo. Use TPM and tamper-proof systems. Does not matter, given enough power/money/force your adversary can walk into that colo and use vampire taps to replug (both power and network) your box without you noticing anything and monitor the rest from there on. As for TPM, who build that piece of hardware and are you sure that a copy of your keys are not kept elsewhere? I used to store crypto secrets on USB smartcards, and have streaming video in the rack, all on UPS. Nowadays, it's even easier. No point to make it too easy. Mallory should earn his keep. At one point or another they just apply rubberhose crypto thus don't make it too difficult. Greets, Jeroen ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Mac?
On 2011-09-09 05:09 , cmeclax-sazri wrote: On Thursday 08 September 2011 22:02:56 Andre Risling wrote: - Who stores the MAC address of the computer you're using? The ISP? An Webmail service? On IPv4, a MAC address goes only as far as the local network (the MAC address my router has on the WAN side goes to my ISP). On IPv6, if you run radvd, the MAC address is incorporated into the IP address of all computers that get their address from radvd. (s/radvd/RA/ as radvd is just an implementation of an IPv6 Router Advertisement Daemon, there are many many others ;) Unless the host has IPv6 Privacy Extensions (RFC4941) enabled or the network uses DHCPv6 (and the host uses that ;) where one is given an effectively static address, or of course if the user itself configures the address manually to something ;) Note that RFC4941 is default on Mac OS X starting with Lion, it is default on all Windows stacks and it can be enabled on Linux. Mostly though it is just an annoyance and anybody wanting to do any kind of tracking can just track the /64 or in most cases even the /48 as that is the address space you will be staying in at that site. And don't forget about having or not having cookies and of course that little thing about your unique signature when you are connecting to certain sites that the rest of the 16 year old don't connect too... (Having a Tor bridge on port 443 of the Google/Facebook/socialoftheday server farm would be quite awesome for that matter ;) Greets, Jeroen ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
[tor-talk] Verifying software signatures (Was: Dutch CA issues fake *.torproject.org cert (among many others))
On 2011-09-03 15:39 , Joe Btfsplk wrote: On 9/2/2011 4:46 PM, and...@torproject.org wrote: On Fri, Sep 02, 2011 at 01:31:53PM -0400, col...@averysmallbird.com wrote 4.5K bytes in 109 lines about: : According to a number of bloggers(1), torproject.org was include among those Here's another blogger for your list, https://blog.torproject.org/blog/diginotar-debacle-and-what-you-should-do-about-it Thanks for all replies on this. I read over several linked articles. Honestly, many avg users won't / can't take time to read it all may not understand it. Question - obviously, Tor isn't the only software or site that could be targeted. What's to prevent necessity of verifying signatures on every d/l software, even mainstream, major developers (if they made it possible)? And if they don't, why wouldn't users of other software be at same risk? Just because we haven't heard about XYZ software fake certificates, does that mean anything? Sure, verifying Tor may be prudent, but what if users have to verify signatures on all software (if available)? Unless it becomes a more automated process, avg users wouldn't devote that kind of time. At least three tools can do this for you: Team Cymru's WinMHR: http://www.team-cymru.org/Services/MHR/WinMHR/ Secunia Personal Software Inspector (PSI): http://secunia.com/vulnerability_scanning/personal/ Spybot Search Destroy: http://www.safer-networking.org Note that these primarily focus on malware spybots and most likely all depend on the wrong hash to be known at the tool that you are using. At least they can state in quite a few cases which binaries are known to them and which standard binaries are off from what they see in the wild. You are also of course, like in a lot of cases, depending on those organizations to do the right thing which again boils down to who to trust. Greets, Jeroen ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
