131 reputation
6
bio website bernd.eckenfels.net
location Karlsruhe, Germany
age 42
visits member for 1 year, 4 months
seen Apr 16 at 3:09

Chief Architect at a german ISV. Java Guru, IT-Security freak, married and pirate.


Apr
16
revised TPM- Symmetric key storage
typos, wording
Apr
8
comment How exactly does the OpenSSL TLS heartbeat (Heartbleed) exploit work?
@supercat no, the openssl layer which processes records will allocate and store the ssl record based on the (first) record length. This stored record is handed to the extension processing, where another length identifier inside the record is used. And the later one happens to have a larger number. So the memcopy starts at the beginning of the valid record and includes data after it. I suspect its a malloced buffer (even when thats a weird thing for high performance network code.) Check the diagnosis link above.
Apr
8
comment How exactly does the OpenSSL TLS heartbeat (Heartbleed) exploit work?
@supercat I dont think the actual buffers are a problem here, the network buffers get overwritten, so when you extract memeory its only the current stuff in memory. And you cannot overwrite stuff you need later on (like cached sessions). And in fact zeroing is quite a high overhead for web servers. I think however some more static allocation of ssl record buffers would not only improve performance but also leaking random system memory (especialy initially allovated "system parameter" memory like the key)
Apr
8
comment How exactly does the OpenSSL TLS heartbeat (Heartbleed) exploit work?
While it is not a flaw in the TLS extention or the TLS protocol, the TLS specification is still somewhat responsible. The layering of messages inside records and the fact that you typically have multiple length specifications inside those records as a very fragile protocol design and asks for trouble. Even worse when implementations do not abstract the segmentation and parsing away with safe helper methods (so all extension parsers need to reinvent the wheel).
Jan
9
awarded  Editor
Jan
9
revised Location to store an encryption key
added 4 characters in body
Jan
9
comment Location to store an encryption key
Yes, the encryption secret and the memcached credentials would have to be stored persistent on the filesystem (accessible to the www-run user). There is not really a way to avoid that (unless you use hardware based protection, but there is not really a good solution as TPM sealing is too slow for transactional data).
Jan
4
answered TextSecure protocol
Jan
4
answered What are the security concerns with turning off Extended protection for authentication in IIS7 on ADFS?
Jan
4
comment Does the Oracle Database Built-in Password Protections prevent pass-the-hash or replay attacks?
Advanced Security allows wrapping the connections in certificate based SSL/TLS.
Jan
4
answered Does the Oracle Database Built-in Password Protections prevent pass-the-hash or replay attacks?
Jan
4
answered TPM- Symmetric key storage
Jan
4
awarded  Commentator
Jan
4
comment Location to store an encryption key
Be carefull with using the password alone: when the user changes the password he wont be able to access the old data. You eighter have to re-encode all old data or you introduce a new indirection: the user hash decrypt a session key. When you set a new password you keep the session key and re-encode it with new user hash. BTW: if you need to store encrypted data from a non user-process, use public key crypto for the session key.
Jan
4
answered Location to store an encryption key
Jan
4
awarded  Critic
Jan
4
comment iptables: plaintext password protection
It might be obvious, but: do not use a common password for all sides and do not use unencrypted password transmits.
Jan
4
comment iptables: plaintext password protection
This does not reliable work depending on the encoding and fragmentation/chunking of the string transferred. But I guess it is (besides using filtering proxies which are better but not perfect in decoding different protocols) the correct answer to the question.
Jan
4
answered Authencity of information displayed on an untrusted device
Jan
5
comment Preventing user supplied javascript from posting to external server
Actually CSP has the "connect-src" attribute, but yes the best separation can be achieved by downloading the plugin from its own origin/domain.