16,255 reputation
12583
bio website
location Brooklyn, NY
age 32
visits member for 2 years, 11 months
seen 1 hour ago
Good Morning how are you, I'm dr jimbob
I'm interested in things.
I'm not a real dr,
But I am a real jim bob.

Have a PhD in Experimental High-Energy Physics, but left academia in mid-2010 to program professionally.

Mostly program/script in python, django, and jquery these days doing mostly web apps.

Also have experience programming in C, C++, java, haskell, php, and (bash) shell more in the past.

Linux as primary OS since 1999, ubuntu user since 2005 (Hoary).


18h
comment Is it possible to use SSH agent for generic data encryption?
@techtonik - I should add there are other agents; e.g., gpg-agent that act similarly to ssh-agent by keeping your passphrase protected encryption keys available for reuse (for a configurable amount of time), so you don't have to keep typing them long passphrases.
1d
comment Is it possible to use SSH agent for generic data encryption?
@techtonik, if you encrypt sensitive data with your private ssh key, you wouldn't want a strong attacker (who can tamper network traffic) to be able to replace the actual sent SSH1 challenge with some sensitive document you encrypted, where ssh happily replies with decrypted document for the tamperer to steal. Would be safer to only leak the hash of the decrypted stream. Also, exposing the full ciphertext using textbook RSA opens it up to several attacks; really should do something like PKCS1v2 before using RSA key. Hashing mitigates some of the more obvious attacks.
1d
comment Is crypto.js vulnerable to heartbleed attack?
This doesn't make any sense. Heartbleed does not give arbitrary access to all the memory on an affected machine. It only can possibly leak memory from the process that is using the vulnerable OpenSSL library (typically a webserver using HTTPS -- e.g., nginx, apache, etc.), see also general description of heartbleed.
1d
comment Is it possible to use SSH agent for generic data encryption?
@techtonik - Updated my answer. To summarize, no, it is not possible to use the private key in ssh-agent for any purpose other than ssh authentication. This is a good thing; otherwise an attacker could extract the private key (without resorting to trying to read the memory of ssh-agent as root).
2d
comment Heartbleed: Why does the client supply the length of the message at all?
@PeterDettman - At that point the standard said just dump the payload and padding -- didn't specify how the payload / padding was differentiated (presumably a header not deigned to mention at that point). Juho first said let's specify the header, (2) and was concerned why these fields are allowed to be so large (concerned about both types) and that if you allow 2^14 - 5= 16379 that requires a uint16 (two byte field).
2d
comment Heartbleed: Why does the client supply the length of the message at all?
@PeterDettman - I added another long section with nuggets seen in the TLS IETF mailing list. It's interesting that many several people noted this potentially opens up side channel attacks. Adding randomized padding seems to be poorly justified based on an analysis of DAE and vague hope to prevent flaws of bad ciphers (meanwhile let's open this side channel).
Apr
13
comment Heartbleed: hackers have already used the vulnerability?
@Clockwork-Muse - Fixed.
Apr
11
comment Ethicality of websites that test other sites for Heartbleed
It is easy to test for heartbleed vulnerability without the risk of getting any valuable data; e.g., you have payload length of 20, but only send 16 bytes (minimum size). Does it fail as it should or does it return 4 extra bytes? Those four bytes of exposed memory will not in anyway be useful to attack the system. However, it does indicate the system is likely vulnerable.
Apr
11
comment How to explain Heartbleed without technical terms?
@MichaelBorgwardt - I tried giving a thorough answer without resorting to just technical jargon or giving silly analogies. I believe some found it helpful. It's not obviously not an "Explain it like I'm a five" or explain it in under a minute, but take the time to explain and related concepts like you are an intelligent adult, even if you aren't a computer/security expert.
Apr
11
comment Does xkcd.com/1353 overstate heartbleed's capability?
@AviD - I think Mr Munroe takes heartbleed very seriously as today's comic also discusses heartbleed in depth (and gives a great summary of it). So I don't see it dripping in sarcasm (besides the obvious comic parts referring to imaginations/paper/clay tablets being safe and the Blade Runner quote).
Apr
11
comment HeartBleed - How to detect compromised websites
There's also this list of Alexa sites that potentially were claimed to be compromised at some point: gist.github.com/dberkholz/10169691
Apr
11
comment How to explain Heartbleed without technical terms?
@Celeritas - Those of the sort of things I expect, (though a sane password manager would only load passwords into memory as necessary and free them quickly). Again, if you patched your OpenSSL on your system to 1.0.1g or used a version before 1.0.1, you are safe from this attack. If you use linux and are familiar with python and have root access, you can explore the contents of memory. Simply find the PID of your web browser (e.g., with top) and then use the python2 script given here, and remember the client attack will only get random chunks.
Apr
10
comment HeartBleed - How to detect compromised websites
I also like the lastpass.com/heartbleed as it stores results of tested sites (was it ever tested to be vulnerable?), gives you information on whether their certificate was recently generated (indicating likely vulnerable in the past), and whether it seems to be running a unix/linux stack (where OpenSSL is more prevalent).
Apr
9
comment Does xkcd.com/1353 overstate heartbleed's capability?
@CodesInChaos - I disagree with "worst so far" but heartbleed and the Debian PRNG failure seem to be on similar scale from my view; both make it trivial to circumvent the security of private keys in trusted widely-deployed software (and existed for years). The biggest difference is that heartbleed won't in most cases let you ssh to random remote machines, but only steal TLS keys and eavesdrop. (While Debian PRNG let you do both).
Apr
9
comment HeartBleed - How to detect compromised websites
@fsb - well the sysadmins should know if they were using a compromised version of openssl and whether they've changed their private keys or not. Granted I don't trust them to reveal it publicly.
Apr
8
comment Lots of failed outgoing sshd attempts. Am I hacked?
I can't easily decipher it from ordinary SSH logs. You could set up a cron job to log this if you wanted, or you could bump up the verbosity level on sshd though. (E.g., edit /etc/ssh/sshd_config and change LOG_LEVEL from INFO to VERBOSE or DEBUG and restart sshd).
Apr
8
comment Lots of failed outgoing sshd attempts. Am I hacked?
@Beau, you can tell who is using ssh by doing ps aux | grep sshd (or use htop). They'll be two processes for every ssh connection on the server; one as root, and the other as the user account who logged in. Interactive sessions will have as the user something like sshd: username@pts/13 (pointing to the terminal -- also try linux command w to see who is on the system). Non-interactive sessions will just say sshd: username for me, but if you note the PID (second column; for my session PID=1342) you will that PID show up in the auth.log: sshd[1342]: error: connect_to 10.0.0.0.
Apr
8
comment What should a website operator do about the Heartbleed OpenSSL exploit?
@OrangeDog - While "possible", that seems to require a completely separate exploit. There's no reason (at least on my systems) that any process having access to an SSH private key also uses TLS. SSH private keys are limited to ssh, sshd, and ssh-agent. So worry about changing your TLS certificates used for HTTPS, FTPS, email, etc. Worry about changing all passwords you've ever used over an HTTPS or TLS connection to a website that may have used OpenSSL in the past three years that you value. But really no legitimate reason to worry about SSH keys.
Apr
8
comment What should a website operator do about the Heartbleed OpenSSL exploit?
It's worth pointing out that OpenSSH is not affected by the OpenSSL bug. While OpenSSH does use openssl for some key-generation functions, it does not use the TLS protocol (and in particular the TLS heartbeat extension that heartbleed attacks). So there is no need to worry about SSH being compromised, though it is still a good idea to update openssl to 1.0.1g or 1.0.2-beta2 (but you don't have to worry about replacing SSH keypairs).
Apr
7
comment Lots of failed outgoing sshd attempts. Am I hacked?
@Beau - Updated my answer with follow-up testing with verbose flag on the ssh tunnel while monitoring both the ssh client and ssh server's output in auth.log, and confirmed this suspicion. If you note the sshd was trying to connect_to on port 80 (well-known port for HTTP) which lead to this suspicion that it was something benign.