Re: towards https everywhere and strict transport security (was: Has there been a change in US banking regulations recently?)
(For what it's worth, I find your style of monocase and ellipses so incredibly difficult to read that I usually delete your postings unread.) as previously mentioned, somewhere back behind everything else ... there is strong financial motivation in the sale of the SSL domain name digital certificates. I don't doubt that this was true when it was the secure sockets layer and e-commerce on the web were just starting up. But I don't think it's accurate any longer. Or rather, who cares how VRSN wants to make money? :) Verisign owns a large portion of the CA market; their market-cap is US$5B. Google's is US$143B, Apple's is US$220B and Microsoft's is US$206B. I mention Google because they are very involved and influential in Internet infrastructure, and Apple because many believe they will be dominant content delivery system, and Microsoft because they were a sponsor of the original SDSI research ( http://people.csail.mit.edu/rivest/sdsi10.html) If someone has a better mousetrap, there's several places that can make it happen and swallow 44% of the SSL market ( https://press.verisign.com/easyir/customrel.do?easyirid=AFC0FF0DB5C560D3version=liveprid=631314releasejsp=custom_97 ) with nary a burp. /r$ -- STSM, WebSphere Appliance Architect https://www.ibm.com/developerworks/mydeveloperworks/blogs/soma/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: towards https everywhere and strict transport security (was: Has there been a change in US banking regulations recently?)
as previously mentioned, somewhere back behind everything else ... there is strong financial motivation in the sale of the SSL domain name digital certificates. While I am *not* arguing that point, per se, if having a better solution would require, or would have required, no more investment than the accumulated profits in the sale of SSL domain name certs, we could have solved this by now. --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: towards https everywhere and strict transport security (was: Has there been a change in US banking regulations recently?)
On 25/08/10 11:04 PM, Richard Salz wrote: A really knowledgeable net-head told me the other day that the problem with SSL/TLS is that it has too many round-trips. In fact, the RTT costs are now more prohibitive than the crypto costs. I was quite surprised to hear this; he was stunned to find it out. Yes, it is inherent in the design assumptions of the early 1990s. At the time, the idea was to secure HTTP, which was (is) a request-response protocol layered over TCP. Now, some of the design features that the designers settled on were: + ignore HTTP and secure TCP + make SSL look just like TCP + third-party authority authentication + no client-side caching of certs And those features they delivered reasonably well. However, if they had dug a bit deeper at the time (unlikely, really unlikely) they would have discovered that the core HTTP protocol is request-response, which means it is two packets, one for request and one for response. Layering HTTP over TCP was a simplification, because just about everyone does that, and still does it for whatever reason. However it was a simplification that ultimately caused a lot more cost than they realised, because it led to further layering, and further unreliability. The original assumptions can be challenged. If one goes to pure request-respose, then the whole lot can be done over datagrams (UDP). Once that is done properly, the protocol can move to 4 packets startup, then cached 2 packets mode. The improvement in reliability is a gift. This is possible, but you have to think outside the box, discard the obsession of layering and the mindtrap of reliable TCP. I've done it, so I know it's possible. Fast, and reliable, too. Lynn as well, it seems. James points out the architectural secret, that security has to be baked into the app, any security below the app is unreliable. Look at the tlsnextprotonec IETF draft, the Google involvement in SPDY, SPDY only takes the low-hanging fruit, IIRC. Very cautious, very conservative, hardly seems worth the effort to me. and perhaps this message as a jumping-off point for both: http://web.archiveorange.com/archive/v/c2Jaqz6aELyC8Ec4SrLY I was happy to see that the interest is in piggy-backing, not in changing SSL/TLS. If you're content with slow, stick with TLS :) Fast starts with a clean sheet of paper. It is of course a complete rewrite, but IMHO the work effort is less than working with layered mistakes of the past. iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: towards https everywhere and strict transport security (was: Has there been a change in US banking regulations recently?)
On 08/26/2010 06:38 AM, d...@geer.org wrote: While I am *not* arguing that point, per se, if having a better solution would require, or would have required, no more investment than the accumulated profits in the sale of SSL domain name certs, we could have solved this by now. the profit from sale of SSL domain name certs had profit motivation pretty much unrelated to the overall costs to the infrastructure ... and so there was an extremely strong champion. simply enhancing DNS and doing real-time trusted public key distribution thru a trusted domain name infrastructure ... was all cost with no champion with strong profit motivation. -- virtualization experience starting Jan1968, online at home since Mar1970 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: towards https everywhere and strict transport security (was: Has there been a change in US banking regulations recently?)
On Thu, 26 Aug 2010, d...@geer.org wrote: as previously mentioned, somewhere back behind everything else ... there is strong financial motivation in the sale of the SSL domain name digital certificates. While I am *not* arguing that point, per se, if having a better solution would require, or would have required, no more investment than the accumulated profits in the sale of SSL domain name certs, we could have solved this by now. Currently, the IETF keyassure WG is working on specifying how to use DNS(SEC) to put the certs in the DNS to avoid the entire CA authentication. It seems to be deciding on certs (not raw keys/hashes) to simplify and re-use the existing TLS based implementations (eg HTTPS) Paul - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: towards https everywhere and strict transport security (was: Has there been a change in US banking regulations recently?)
Richard Salz writes: A really knowledgeable net-head told me the other day that the problem with SSL/TLS is that it has too many round-trips. In fact, the RTT costs are now more prohibitive than the crypto costs. I was quite surprised to hear this; he was stunned to find it out. Cryptographic operations are measured in cycles (i.e. nanoseconds now); network operations are measured in milliseconds. That should not be a stunning surprise. What is neither stunning nor surprising, but continually sad, is that web developers don't measure anything. Predictably, web app performance is unnecessarily terrible. I once asked some developers why they couldn't use HTTPS. Performance! was the cry. Ok, I said. What is your performance target, and by how much does HTTPS make you miss it? Maybe we can optimize something so you can afford HTTPS again. As fast as possible!!! was the response. When I pointed out that their app sent AJAX requests and responses that were tens or even hundreds of KB every couple seconds, and that as a result their app was barely usable outside their LAN, I was met with blank stares. Did they use HTTP persistent connections, TLS session resumption, text content compression, maximize HTTP caching, ...? I think you can guess. :) Efforts like SPDY are the natural progression of organizations like Google *WHO HAVE ALREADY OPTIMIZED EVERYTHING ELSE*. Until you've optimized the content and application layers, worrying about the transport layers makes no sense. A bloated app will still be slow when transported over SPDY. Developers are already under the dangerous misapprehension that TLS is too expensive. When they hear security experts and cryptographers mistakenly agree, the idea will stick in their minds forever; we will have failed. The problem comes from insufficiently broad understanding: the sysadmins fiddle their kernel tuning knobs, the security people don't understand how applications work, and the developers call malloc 5,000 times and perform 2,500 I/O ops just to print Hello, World. The resulting software is unsafe, slow, and too expensive. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: towards https everywhere and strict transport security (was: Has there been a change in US banking regulations recently?)
Also, note that HSTS is presently specific to HTTP. One could imagine expressing a more generic STS policy for an entire site A really knowledgeable net-head told me the other day that the problem with SSL/TLS is that it has too many round-trips. In fact, the RTT costs are now more prohibitive than the crypto costs. I was quite surprised to hear this; he was stunned to find it out. Look at the tlsnextprotonec IETF draft, the Google involvement in SPDY, and perhaps this message as a jumping-off point for both: http://web.archiveorange.com/archive/v/c2Jaqz6aELyC8Ec4SrLY I was happy to see that the interest is in piggy-backing, not in changing SSL/TLS. /r$ -- STSM, WebSphere Appliance Architect https://www.ibm.com/developerworks/mydeveloperworks/blogs/soma/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: towards https everywhere and strict transport security (was: Has there been a change in US banking regulations recently?)
On Aug 25, 2010, at 9:04 20AM, Richard Salz wrote: Also, note that HSTS is presently specific to HTTP. One could imagine expressing a more generic STS policy for an entire site A really knowledgeable net-head told me the other day that the problem with SSL/TLS is that it has too many round-trips. In fact, the RTT costs are now more prohibitive than the crypto costs. I was quite surprised to hear this; he was stunned to find it out. This statement is quite correct. I know of at least one major player that was very reluctant to use SSL because of this issue; the round trips, especially on intercontinental connections, led to considerable latency, which in turn hurt the perceived responsiveness of their service. We need to do something about the speed of light. Is anyone working on hyperwave or subether technologies? --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: towards https everywhere and strict transport security (was: Has there been a change in US banking regulations recently?)
On 08/25/2010 09:04 AM, Richard Salz wrote: Also, note that HSTS is presently specific to HTTP. One could imagine expressing a more generic STS policy for an entire site A really knowledgeable net-head told me the other day that the problem with SSL/TLS is that it has too many round-trips. In fact, the RTT costs are now more prohibitive than the crypto costs. I was quite surprised to hear this; he was stunned to find it out. Look at the tlsnextprotonec IETF draft, the Google involvement in SPDY, and perhaps this message as a jumping-off point for both: http://web.archiveorange.com/archive/v/c2Jaqz6aELyC8Ec4SrLY I was happy to see that the interest is in piggy-backing, not in changing SSL/TLS. the work on HSP (high-speed protocol) in the late 80s was to do reliable transmission in minimum 3-packet exchange; compared to 5-packet minimum for VMTP (rfc1045) and 7-packet minimum for tcp (disclaimer, i was on related technical advisory board for HSP ... while at IBM ... over strong objections from the communication division; but that also strong protested that we had come up with 3-tier architecture and were out pitching it to customer executives ... at a time when they were attempting to get the client/server genie back into the terminal emulation bottle) then SSL theoretically being stateless on top of tcp added a whole bunch of additional chatter. there has frequently between changing trade-offs between transmission and processing ... but SSL started out being excessive in both transmission and processing (in addition to having deployment requirement that the user understand the relationship between the website they believed they were talking to and the URL they had to supply to the browser a requirement that was almost immediately violated). my pitch forever has been to leverage key distribution piggy-backed on domain name to ip-address (dns) response ... and use that to do encrypted/validated reliable transaction within HSP 3-packet minimum exchange. as previously mentioned, somewhere back behind everything else ... there is strong financial motivation in the sale of the SSL domain name digital certificates. -- virtualization experience starting Jan1968, online at home since Mar1970 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: towards https everywhere and strict transport security (was: Has there been a change in US banking regulations recently?)
A really knowledgeable net-head told me the other day that the problem with SSL/TLS is that it has too many round-trips. In fact, the RTT costs are now more prohibitive than the crypto costs. Yes, although that's a different class of issue from the ones we're trying to address in hasmat and keyassure. these two drafts comprise the approach Adam Langley (of google) is presently pursuing wrt both fast TLS startup (snapstart) and support for NextProtocolNegotiation (during TLS handshake).. http://tools.ietf.org/html/draft-agl-tls-nextprotoneg http://tools.ietf.org/html/draft-agl-tls-snapstart Note that the motivation for draft-agl-tls-nextprotoneg is so-called websockets, which are being worked on in the IETF HYBI (hypertext bidirectional) WG http://datatracker.ietf.org/wg/hybi/ =JeffH - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: towards https everywhere and strict transport security (was: Has there been a change in US banking regulations recently?)
On Sun, Aug 22, 2010 at 11:51:01AM -0400, Anne Lynn Wheeler wrote: On 08/22/2010 06:56 AM, Jakob Schlyter wrote: There are a lot of work going on in this area, including how to use secure DNS to associate the key that appears in a TLS server's certificate with the the intended domain name [1]. Adding HSTS to this mix does make sense and is something that is discussed, e.g. on the keyassure mailing list [2]. There is large vested interested in Certification Authority industry selling SSL domain name certificates. A secure DNS scenario is having a public key registered at the time the domain name is registered ... and then a different kind of TLS ... where the public key is returned in piggy-back with the domain name to ip-address mapping response. for the conservative - they may want to verify the DNSSEC trust chains for both the domain name and the IP address. e.g. is it the same EV cert at the end of both validation checks. --bill - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Has there been a change in US banking regulations recently?
On Aug 16, 2010, at 9:19 49PM, John Gilmore wrote: who's your enemy? The NSA? The SVR? Or garden-variety cybercrooks? Enemy? We don't have to be the enemy for someone to crack our security. We merely have to be in the way of something they want; or to be a convenient tool or foil in executing a strategy. John, as you yourself have said, cryptography is a matter of economics. Other than a few academics, people don't factor large numbers for fun; rather, they want the plaintext or the ability to forge signatures. Is factoring the best way to do that? Your own numbers suggest that it is not. You wrote After they've built 50, which perhaps only take six months to crack a key, will YOUR key be one of the 100 keys that they crack this year? 100 keys, perhaps multiplied by 10 for the number of countries that will share the effort, means 1000 keys/year. How many *banks* have SSL keys? If you want to attack one of those banks, which is *cheaper*, getting time on a rare factoring machine, or finding some other way in, such as hacking an endpoint? For that matter, don't forget Morris' three Bs: burglary, bribery, and blackmail. (Aside: I was once discussing TWIRL with someone who has ties to the classified community. When I quoted solution speeds of the we're discussing, he chortled, saying that the political fight over whose solutions were more valuable would paralyze things.) If the threat is factoring, there are cheaper defenses than going to 1024-bit keys. For example, every one under a given CA can issue themselves subcertificates. For communication keys, use D-H; it's a separate solution effort for each session. (Yes, it's cheaper if the modulus is held constant.) Cracking the signing key won't do any good, because of perfect forward secrecy. You don't need long keys when they're used solely for short-lived authentication -- DNSSEC comes to mind. Now -- all that said, I agree that 2048-bit keys are a safer choice. However, defenders have to consider economics, too, and depending on what they're protecting it may not be a smart choice. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Has there been a change in US banking regulations recently?
On 2010-08-15 7:59 AM, Thor Lancelot Simon wrote: Indeed. The way forward would seem to be ECC, but show me a load balancer or even a dedicated SSL offload device which supports ECC. For sufficiently strong security, ECC beats factoring, but how strong is sufficiently strong? Do you have any data? At what point is ECC faster for the same security? - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Has there been a change in US banking regulations recently?
On Fri, Aug 13, 2010 at 02:55:32PM -0500, eric.lengve...@wellsfargo.com wrote: There are some possibilities, my co-workers and I have discussed. For purely internal systems TLS-PSK (RFC 4279) provides symmetric encryption through pre-shared keys which provides us with whitelisting as well as removing asymmetric crypto. [...] For purely internal systems Kerberos is really the way to go, mostly because it's so easy to deploy nowadays. TLS-PSK is not a useful way of building any but the smallest networks, and for two reasons: a) there's no agreed PBKDF and password salting mechanisms, so passwords are out, b) there's no enrolment mechanism, so PSK setup is completely ad-hoc. Nico -- - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Has there been a change in US banking regulations recently?
On Aug 15, 2010, at 1:17 30PM, Peter Gutmann wrote: Ray Dillinger b...@sonic.net writes: On Fri, 2010-08-13 at 14:55 -0500, eric.lengve...@wellsfargo.com wrote: The big drawback is that those who want to follow NIST's recommendations to migrate to 2048-bit keys will be returning to the 2005-era overhead. Either way, that's back in line with the above stated 90-95% overhead. Meaning, in Dan's words 2048 ain't happening. I'm under the impression that 2048 keys are now insecure mostly due to advances in factoring algorithms Insecure against what? Right -- who's your enemy? The NSA? The SVR? Or garden-variety cybercrooks? Given the million [0] easier attack vectors against web sites, which typically range from trivial all the way up to relatively easy, why would any rational attacker bother with factoring even a 1024-bit key, with a difficulty level of quite hard? It's not as if these keys have to remain secure for decades, since the 12-month CA billing cycle means that you have to refresh them every year anyway. That depends on what you're protecting. If it's the 4-digit PIN to billion-zorkmid bank accounts, they key needs to remain secure for many years, given how seldom PINs are changed. Given both the state of PKI and the practical nonexistence of attacks on crypto of any strength because it's not worth the bother, would the attackers even notice if you used a 32-bit RSA key? How would an adversary effectively scale and monetise an attack based on being able to break an RSA key, even if it was at close to zero cost? The unfortunate effect of such fashion-statement crypto recommendations as you must use 2K bit keys, regardless of the threat environment is that what it actually says is you must not use SSL on your web site. Le mieux est l'ennemi du bien strikes again. Yup. [0] Figure exaggerated slightly for effect. But only slightly exaggerated... --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
RE: Has there been a change in US banking regulations recently?
On Fri, 2010-08-13 at 14:55 -0500, eric.lengve...@wellsfargo.com wrote: Moore's law helped immensely here. In the last 5 years systems have gotten about 8 times faster, reducing the processing cost of crypto a lot. The big drawback is that those who want to follow NIST's recommendations to migrate to 2048-bit keys will be returning to the 2005-era overhead. Either way, that's back in line with the above stated 90-95% overhead. Meaning, in Dan's words 2048 ain't happening. I'm under the impression that 2048 keys are now insecure mostly due to advances in factoring algorithms that make the attack and the encryption effort closer to, but by no means identical to, scaling with the same function of key length. This makes the asymmetric cipher have a lower ratio of attack cost to encryption cost at any given key length, but larger key lengths still yield *much* higher ratios of attack cost to encryption cost. At 2048 bits, I think that with Moore's law over the next decade or two dropping attack costs and encryption costs by the same factor, attack costs should remain comfortably out of reach while encryption costs return to current levels now practical for shorter keys. Of course, this reckons without the potential for unforseen advances in factoring or Quantum computing. There are some possibilities, my co-workers and I have discussed. For purely internal systems TLS-PSK (RFC 4279) provides symmetric encryption through pre-shared keys which provides us with whitelisting as well as removing asymmetric crypto. That's probably a good idea. We've placed a lot of stock in public- key systems because of some neat mathematical properties that seemed to conform to someone's needs for an online business model involving the introduction of strangers who want to do business with each other. But if you can handle key distribution internally by walking down the hall or mailing a CD-ROM preloaded with keys instead of by trusting the network the keys are supposed to secure, you really don't need Public-key crypto's neat mathematical properties. Bear - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
RE: Has there been a change in US banking regulations recently?
Ray Dillinger b...@sonic.net writes: On Fri, 2010-08-13 at 14:55 -0500, eric.lengve...@wellsfargo.com wrote: The big drawback is that those who want to follow NIST's recommendations to migrate to 2048-bit keys will be returning to the 2005-era overhead. Either way, that's back in line with the above stated 90-95% overhead. Meaning, in Dan's words 2048 ain't happening. I'm under the impression that 2048 keys are now insecure mostly due to advances in factoring algorithms Insecure against what? Given the million [0] easier attack vectors against web sites, which typically range from trivial all the way up to relatively easy, why would any rational attacker bother with factoring even a 1024-bit key, with a difficulty level of quite hard? It's not as if these keys have to remain secure for decades, since the 12-month CA billing cycle means that you have to refresh them every year anyway. Given both the state of PKI and the practical nonexistence of attacks on crypto of any strength because it's not worth the bother, would the attackers even notice if you used a 32-bit RSA key? How would an adversary effectively scale and monetise an attack based on being able to break an RSA key, even if it was at close to zero cost? The unfortunate effect of such fashion-statement crypto recommendations as you must use 2K bit keys, regardless of the threat environment is that what it actually says is you must not use SSL on your web site. Le mieux est l'ennemi du bien strikes again. Peter. [0] Figure exaggerated slightly for effect. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Has there been a change in US banking regulations recently?
Anne Lynn Wheeler writes: subset ... was based on computational load caused by SSL cryptography in the online merchant scenario, it cut thruput by 90-95%; alternative to handle the online merchant scenario for total user interaction would have required increasing the number of servers by factor of 10-20. When was this *ever* true? Seriously. N-tier applications are I/O-bound in at least N ways. Common development practice leads to excessive message sizes in most of the N tiers. Rare is the web site with a low N and small message sizes. Fire up your HTTP proxy and/or packet sniffer and compare Google to, well, just about everyone else. Now that your packet sniffer and/or proxy is started up, it is also a fun drinking game to play Spot The SSL Server Misconfiguration. When you see HTTP persistence turned off, take a shot. When you see TLS session resumption turned off or sessions destroyed after a short period of time, take a shot. When you see a new TLS session for each new HTTP request, take three shots (in addition to the shot you probably took when noticing HTTP persistence turned off, because let's face it probably was). If the misconfiguration is at a CDN, take three shots and smash your face with a frying pan. The game is usually played with Jaegermeister, but if you are testing a bank site, you can afford good scotch. The adjudicating committee rarely disqualifies a contestant on the basis of liquor, although I'd still advise against the use of vodka. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Has there been a change in US banking regulations recently?
On 08/13/2010 03:16 PM, Chris Palmer wrote: When was this *ever* true? Seriously. re: http://www.garlic.com/~lynn/2010m.html#50 ... original design/implementation. The very first commerce server implementation by the small client/server startup (that had also invented SSL) ... was mall paradigm, development underwritten by large telco (they were looking at being major outsourcer of electronic commerce servers) ... then the individual store implementation was developed. we had previously worked with two people responsible for commerce server (at small client/server startup) on ha/cmp ... they are mentioned in this old posting about jan92 meeting in ellison's conference room http://www.garlic.com/~lynn/95.html#13 they then left to join the small client/server startup ... and we also leave what we had been doing. we then get brought in as consultants because they want to do payment transactions on their server ... wanting to use this technology called SSL that had been invented at the startup. We have to go thru the steps of mapping the technology to payment business processes ... including backend use involving the interaction between commerce servers and the payment gateway; the payment gateway sitting on the internet and interface to acquiring network backends ... misc. past posts mentioning payment gateway http://www.garlic.com/~lynn/subnetwork.html#gateway we also have to do walkthru/audits of several of these new businesses calling themselves Certification Authorities that were selling SSL domain name digital certificates ... some past posts http://www.garlic.com/~lynn/subpubkey.html#sslcerts approx. in the same era, but not exactly the same time (when webservers were seeing the ssl cryptographic load dropping back to only using it for payment) ... some of the larger websites were starting to first see a plain tcp/ip scaleup issue ... having to do with tcp being originally designed as session protocol ... and was effectively being misused by HTTP. As a result most vendor implementations hadn't optimized session termination ... which was viewed as infrequent event (up until HTTP). There was six month period or so ... that the large websites saw their processors spending 90-95% of the cpu running the FINWAIT list (as part of session termination). The small client/server startup was also seeing (other) scaleup problems in their server platforms used for downloading products (especially browser product download activity) ... and in constant cycle of adding servers. This was before rotating front-ends ... so users were asked to manually specify URL of specific server. Their problem somewhat cleared up when they installed a large sequent box ... both because of the raw power of the sequent server ... and also because sequent claimed to have addressed the session terminal efficiency sometime previously (related to commercial unix accounts with 20,000 concurrent telnet sessions). For other topic drift ... I believe the first rotating, load-balancing front-ends was with custom modified software for routers at google. -- virtualization experience starting Jan1968, online at home since Mar1970 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Has there been a change in US banking regulations recently?
On Fri, Aug 13, 2010 at 09:32:57AM -0700, Jeff Simmons wrote:
It wouldn't surprise me if there's been some blowback from the
adoption of PCI-DSS (Payment Card Industry Data Security
Standards). As someone who has had to help several small to medium
size businesses comply with these 'voluntary' standards, the irony
of the fact that the big banks that require them often aren't in
compliance themselves hasn't escaped my notice.
In the past month, we've had several customers at work suddenly
insist that we make modifications to their firewalls and/or load
balancers to redirect *all* incoming HTTP traffic to HTTPS (which of
course isn't always entirely sane to do on proxying devices, but
they apparently don't trust their server admins to maintain an HTTP
redirect). Most of them cited requirements from their PCI-DSS
auditors. One apparently was outright told that their redirects were
a security problem because they presented an open socket on port
80, and they needed to be refusing all HTTP to their servers at the
firewall. I think we gave them sufficient wording to convince their
auditor that blocking access to the redirect itself wasn't going to
do anyone any good.
--
{ IRL(Jeremy_Stanley); PGP(97AE496FC02DEC9FC353B2E748F9961143495829);
SMTP(fu...@yuggoth.org); IRC(fu...@irc.yuggoth.org#ccl); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER(fu...@yuggoth.org);
MUD(kin...@katarsis.mudpy.org:6669); WWW(http://fungi.yuggoth.org/); }
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
RE: Has there been a change in US banking regulations recently?
Ann Lynn Wheeler wrote: the original requirement for SSL deployment was that it was on from the original URL entered by the user. The drop-back to using SSL for only small subset ... was based on computational load caused by SSL cryptography in the online merchant scenario, it cut thruput by 90-95%; alternative to handle the online merchant scenario for total user interaction would have required increasing the number of servers by factor of 10-20. One possibility is that the institution has increased the server capacity ... and/or added specific hardware to handle the cryptographic load. Moore's law helped immensely here. In the last 5 years systems have gotten about 8 times faster, reducing the processing cost of crypto a lot. I'm familiar with one site that has 24 servers evenly divided across three geographical areas. To entirely SSL-enable their site required only one new server at each site. Meanwhile, load-balancing SSL terminator/accelerators have improved even faster due to improvements in load-balancing, network compression, etc. So putting one of them in front of a previously naïve load-balancing scheme, like basic round-robin would provide enough offloading to SSL-enable an entire site. The big drawback is that those who want to follow NIST's recommendations to migrate to 2048-bit keys will be returning to the 2005-era overhead. Dan Kaminsky provided some benchmarks in a different thread on this list [1] that showed 2048-bit keys performing at 1/9th of 1024-bit. My own internal benchmarks have been closer to 1/7th to 1/8th. Either way, that's back in line with the above stated 90-95% overhead. Meaning, in Dan's words 2048 ain't happening. There are some possibilities, my co-workers and I have discussed. For purely internal systems TLS-PSK (RFC 4279) provides symmetric encryption through pre-shared keys which provides us with whitelisting as well as removing asymmetric crypto. Or, possibly stepping up the key-size in accordance with Moore's law, which would take several years to reach 2048-bit, but each time a certificate expired the new certificate could be issued with the next higher keylength. Besides, I think we all know that NIST's 2010 algorithm transaction isn't going to happen on schedule. At the IEEE key management summit back in May (IIRC) Elaine Barker from NIST presented a back-off talk in which NIST only strongly recommends 110-bit security by 2011, and pushes the real deadline out to the end of 2013. That was subsequently released as a draft SP800-131; available for comments [2] Of course, the industry had five years to plan for this, and no major vendors seem to be ready. Most comments are essentially vendors sighing with relief. [1] http://www.mail-archive.com/cryptography@metzdowd.com/msg11245.html [2] http://csrc.nist.gov/publications/drafts/800-131/draft-sp800-131_spd-june2010.pdf Eric Lengvenis InfoSec Arch. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Has there been a change in US banking regulations recently?
On Fri, Aug 13, 2010 at 02:55:32PM -0500, eric.lengve...@wellsfargo.com wrote: The big drawback is that those who want to follow NIST's recommendations to migrate to 2048-bit keys will be returning to the 2005-era overhead. Dan Kaminsky provided some benchmarks in a different thread on this list [1] that showed 2048-bit keys performing at 1/9th of 1024-bit. My own internal benchmarks have been closer to 1/7th to 1/8th. Either way, that's back in line with the above stated 90-95% overhead. Meaning, in Dan's words 2048 ain't happening. Indeed. The way forward would seem to be ECC, but show me a load balancer or even a dedicated SSL offload device which supports ECC. I'm not even certain the popular clients, which are usually well ahead of everything else in terms of cryptography support, can cope with it. The only place it seems to be consistently used is in proprietary client/server software for mobile devices, as has been the case for years. Thor - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Has there been a change in US banking regulations recently?
As part of a thread on another list, I noticed that Bank of America, who until recently didn't bother protecting the page where users are expected to enter their credentials with anything more substantial than a GIF of a padlock, now finally use HTTPS on their home page, and redirect HTTP to HTTPS (this only took them, what, about ten years to get right? Or is it fifteen? When did BofA first get a web presence?). Wachovia now do it too. And Citibank at least redirect you to an HTTPS page. And so does US Bank, after asking for your ID. What on earth happened? Was there a change in banking regulations in the last few months? Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Has there been a change in US banking regulations recently?
On Friday 13 August 2010 04:59, Peter Gutmann wrote: As part of a thread on another list, I noticed that Bank of America, who until recently didn't bother protecting the page where users are expected to enter their credentials with anything more substantial than a GIF of a padlock, now finally use HTTPS on their home page, and redirect HTTP to HTTPS (this only took them, what, about ten years to get right? Or is it fifteen? When did BofA first get a web presence?). Wachovia now do it too. And Citibank at least redirect you to an HTTPS page. And so does US Bank, after asking for your ID. What on earth happened? Was there a change in banking regulations in the last few months? Peter. It wouldn't surprise me if there's been some blowback from the adoption of PCI-DSS (Payment Card Industry Data Security Standards). As someone who has had to help several small to medium size businesses comply with these 'voluntary' standards, the irony of the fact that the big banks that require them often aren't in compliance themselves hasn't escaped my notice. -- Jeff Simmons jsimm...@goblin.punk.net Simmons Consulting - Network Engineering, Administration, Security You guys, I don't hear any noise. Are you sure you're doing it right? -- My Life With The Thrill Kill Kult - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Has there been a change in US banking regulations recently?
What on earth happened? Was there a change in banking regulations in the last few months? No, but we know that banks move in herds, and they mostly talk to each other, not anyone with outside expertise. More likely someone noticed that computers are a lot faster than they were a decade ago, you can do all the crypto you want and your 8 core 3 GNz servers are still I/O bound, so the traditional folklore that SSL is so slow you use it only where absolutely mandatory no longer applies and you might as well use SSL on everything. Then he went to a meeting and told all his friends. I've been noticing something similar at abuse.net, a service I run where people can publish their domains' abuse contacts. The folklore in small credit unions is that you're supposed to hide your domain's registration details using a proxy service, I think due to a misreading of an old letter from the NCUA. Earlier this year someone at a meeting must have told them that it would be a good idea to register with abuse.net, so I've been getting a stream of attempted registrations from small credit unions with proxy registration, which I reject. About half of them get the hint, turn off the proxy, and try again, the other half give up. R's, John - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Has there been a change in US banking regulations recently?
What on earth happened? Was there a change in banking regulations in the last few months? Possibly it's related to PCI DSS and other work that BITS has been doing. Also, if one major player cleans up their act and sings about how cool they are, then that can cause the ice to break. Another possibility is that a number of people in financials have been able to get security funding despite the banking disasters because the risk managers know that the last thing they need is a security brouhaha while they are partially owned by government and thus voters. I bet on synergies between both. If I were a CSO at a bank, I might encourage a colleague to make a presentation about how their security cleanups position them to get an advantage at getting out from under the thumb of the feds over their competitors. Then I would make sure the finance guys got a leaked copy. Jon - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
RE: Has there been a change in US banking regulations recently?
Jeff Simmons wrote: It wouldn't surprise me if there's been some blowback from the adoption of PCI-DSS (Payment Card Industry Data Security Standards). As someone who has had to help several small to medium size businesses comply with these 'voluntary' standards, the irony of the fact that the big banks that require them often aren't in compliance themselves hasn't escaped my notice. I'd like to clarify a bit. PCI-DSS wasn't developed by the big banks. It isn't usually enforced by big banks except insofar as they are liable for PCI-DSS compliance when outsourcing to or partnering with other companies. So they may be forcing it on the SMBs you've worked with because they're liable in some way. PCI-DSS was the brainchild of Visa. I'm a member of X9F (X9F6 is the payment card security standards committee) and we wrote an open letter back in 2005 to Visa and Mastercard asking them not to set new, separate standards for the financial sector but to work from within X9F. They ignored us. Even though you clearly indicate that they aren't truly voluntary via your use of quotes, when the PCI group (VISA et al.) can unilaterally level huge fines and/or penalties for non-compliance they really are compulsory. Luckily, PCI-DSS compliance != security. Or is that unluckily because of how much money is wasted complying that could be better spent securing. Eric Lengvenis InfoSec Arch - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Has there been a change in US banking regulations recently?
On 08/13/2010 02:12 PM, Jon Callas wrote: What on earth happened? Was there a change in banking regulations in the last few months? Possibly it's related to PCI DSS and other work that BITS has been doing. Also, if one major player cleans up their act and sings about how cool they are, then that can cause the ice to break. Another possibility is that a number of people in financials have been able to get security funding despite the banking disasters because the risk managers know that the last thing they need is a security brouhaha while they are partially owned by government and thus voters. I bet on synergies between both. If I were a CSO at a bank, I might encourage a colleague to make a presentation about how their security cleanups position them to get an advantage at getting out from under the thumb of the feds over their competitors. Then I would make sure the finance guys got a leaked copy. Jon the original requirement for SSL deployment was that it was on from the original URL entered by the user. The drop-back to using SSL for only small subset ... was based on computational load caused by SSL cryptography in the online merchant scenario, it cut thruput by 90-95%; alternative to handle the online merchant scenario for total user interaction would have required increasing the number of servers by factor of 10-20. One possibility is that the institution has increased the server capacity ... and/or added specific hardware to handle the cryptographic load. A lot of banking websites are not RYO (roll-your-own), internally developed ... but stuff they by from vendor and/or have the website wholly outsourced. Also some number of large institutions have their websites outsourced to vendors with large replicated sites at multiple places in the world ... and users interaction gets redirected to the closest server farm. I've noticed this periodically when the server farm domain name and/or server farm SSL certificate bleeds thru ... because of some sort of configuration and/or operational problems (rather than seeing the institution SSL certificate that I thot I was talking to). Another possibility is that the vendor product that they may be using for the website and/or the outsourcer that is being used ... has somehow been upgraded (software /or hardware). -- virtualization experience starting Jan1968, online at home since Mar1970 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
