| bio | website | phonefactor.com |
|---|---|---|
| location | Leawood, KS, USA | |
| age | ||
| visits | member for | 1 year, 9 months |
| seen | Jan 29 '12 at 22:31 | |
| stats | profile views | 50 |
CTO of PhoneFactor
|
Aug 12 |
awarded | Yearling |
|
Jun 8 |
awarded | Caucus |
|
Apr 20 |
awarded | Nice Answer |
|
Sep 30 |
answered | Should I ignore the BEAST SSL exploit and continue to prefer AES? |
|
Sep 30 |
answered | Can wildcard certificates hide/obscure the hostname in a TLS connection? |
|
Sep 30 |
answered | Does SSL/TLS (https) hide the urls being accessed |
|
Sep 29 |
answered | What should I know before configuring Perfect Forward Secrecy? |
|
Sep 28 |
awarded | Tumbleweed |
|
Sep 26 |
comment |
TLS 1.0 JavaScript injection vulnerability (BEAST): what to do client-side? It's worse than that - browsers need to offer TLS 1.1/1.2 and need to NOT accept downgrade to SSL3. Servers, likewise, need to turn on TLS 1.1/1.2 and disable support for SSL3. Simply getting both sides to enable TLS 1.1+ is not sufficient without simultaneously turning off SSL3. |
|
Sep 26 |
comment |
What can I do about TLS 1.0 javascript injection vulnerability on my server? And fwiw, the empty opening message has compat problems (still), but a one-byte opening message works, and is what Chrome is doing. |
|
Sep 26 |
awarded | Critic |
|
Sep 26 |
comment |
What can I do about TLS 1.0 javascript injection vulnerability on my server? I think this advice no longer holds since the paper was released. Browsers can indeed fix this unilaterally (well, clients, more generally), but servers still have an independent need to ensure confidentiality, and at least for a while, they can't rely on the client to do the right thing. |
|
Sep 26 |
revised |
What can I do about TLS 1.0 javascript injection vulnerability on my server? added 350 characters in body |
|
Sep 26 |
comment |
What can I do about TLS 1.0 javascript injection vulnerability on my server? If you enable newer versions on the server, you'll still be subject to a downgrade attack unless you disable 1.0/1.1. There are browsers with 1.1 support in the wild (IE9, for instance, but it's disabled by default). Still, until you are comfortable turning away all <1.1 traffic, protocol version is not a useful server-side mitigation. |
|
Sep 25 |
revised |
SSL Breach - Does the latest BEAST vulnerability mean SSL Issuers now have to worry about integrity? added 237 characters in body |
|
Sep 25 |
comment |
Is security increased by using a subdomain per customer in a web-app? Just make sure you have the operational and organizational controls in place to guarantee that. |
|
Sep 25 |
comment |
What ciphers should I use in my web server after I configure my SSL certificate? Whether or not clients patch is not entirely the point - servers have an independent need to protect themselves from attackers, even in the face of vulnerable clients. There are always other ways to attack someone, but that doesn't mean that this one doesn't need to be addressed, of course. |
|
Sep 23 |
comment |
Is security increased by using a subdomain per customer in a web-app? Exactly; it's a little worse, though - you're depending on others NOT to set a cookie you depend on in some way. |
|
Sep 23 |
revised |
What can I do about TLS 1.0 javascript injection vulnerability on my server? added 204 characters in body |
|
Sep 23 |
comment |
What ciphers should I use in my web server after I configure my SSL certificate? RC4 is widely supported, and there are browsers that offer it as a preference. Also, if the attack is as bad as advertised, it's a very serious break, so I wouldn't be comfortable with a blanket recommendation to sit back and wait for a fix. |