SSL Optimization Over WAN Needs Scrutiny

coondoggie writes with word of the expansion of WAN optimization appliances to handle SSL traffic and the security concerns this brings up. From the article: "With more and more WAN optimization vendors extending their capabilities to include encrypted traffic, corporate IT executives have a decision to make: Should they trust the security these devices provide? Rather than passing through SSL sessions between clients and servers located in remote data centers, some WAN optimization gear can terminate the SSL sessions, shrink the traffic, and re-encrypt it for the next leg of the trip. These chains of encrypted sessions introduce potential vulnerabilities that different vendors address in different ways. SSL traffic represents a growing percentage of total traffic on WAN links, according to Forrester Research. So SSL support in WAN optimization appliances will become more important to businesses that want to keep traffic secure while minimizing the size of their WAN links."

Comments

Fist prost

[Anonymous Coward]

gnaa.us

Never trust an analyst

[Watson Ladd]

The cited analyst is confusing proxying conducted by someone the site designates vs. yourself. One doesn't let anyone do anything they can't already. The other means you have all your confidential information sitting on a device that is not engineered for efficency.

What about Akamai?

[Anonymous Coward]

What about Akamai's SSL encryption? http://www.akamai.com?

Re:What about Akamai?

[pipacs]

From TFA:

The fact that SSL sessions are being proxied shouldnt scare anyone away, says Joe Skorupa, an analyst with Gartner. Akamai, for instance, proxies SSL transactions - some of them involving e-commerce - for its customers, he says. Theres precedent for doing it and doing it where significant amounts of money are at risk

Let's just hope they are all good guys.

I'm tired of hearing

[Anonymous Coward]

the general public complain about options that backhaul ISP providers use to help reduce their expenses, increase performance and keep costs down as much as possible. Backhaul of circuits in remote sites with Sat bandwidth is enormously expensive. With new bandwidth intensive applications coming out all of the time, an ISP can either optimize their traffic to support the new apps, or pass the increase of their upgrades on to their users and then listen to the users whine about the new cost. The internet was never and should never be considered a replacement for a private WAN if data security is of the utmost importance for your business. Does it work - yes. Is it a replacement - no. ISPs are not in business to provide non-profit service to corporations who choose to use a cheaper method of transporting their private data and then listen to the complaints about such matters. If you consider your ISP to be doing something disreputable with your encrypted traffic - find another ISP or switch to a private WAN circuit.

Re:I'm tired of hearing

[Anonymous Coward]

If you read the fine print of SBC/ATT's "private WAN" contract, even for frame relay service, they have the right to put your traffic on the public internet w/o any encryption. Who knows how much they do.

Re:I'm tired of hearing

[Anonymous Coward]

Traditional private WAN circuits are point-to-point circuits (T1/frac T1). They never touch the internet.

Re:I'm tired of hearing

[jafiwam]

I am tired of cheap ass providers that have the shittiest proxy server service on the damn planet letting my users think the server is "under construction" for two days because of their pile of shit proxy decided to poke while I was rebooting and is too niggardly to go and check for a new version quicker than 48 hours later.

Make your shit work right, and nobody will notice it, dumbfuck.

How bout them apples Mr. Too Chickenshit To Use A Real Name?

Re:I'm tired of hearing

[Anonymous Coward]

I am tired of cheap ass providers that have the shittiest proxy server service on the damn planet letting my users think the server is "under construction" for two days because of their pile of shit proxy decided to poke while I was rebooting and is too niggardly to go and check for a new version quicker than 48 hours later. Make sure that the "under construction" pages are correctly tagges with nocache and friends. In other words, do your homework and stop calling people names.

Cheers, Kuba

Re:I'm tired of hearing

[AI0867]

what makes you believe those proxy servers actually listen to those headers? I've had proxies completely cache an interactive website, after seeing exactly the same data three times I noticed the timestamp was that of half an hour ago.

Hm.

[Anonymous Coward]

Honestly, I can't say I give a shit about this. But I run a small-potatoes operation, rather quite out of the league of the big boys and their network appliances.

Microsoft ISA Server

[Anonymous Coward]

Microsoft's ISA (Internet Security and Acceleration) Server has been providing functionality to accomplish just this (reverse proxy publishing of web servers, acting as the SSL endpoint, passing on unencrypted or re-ssl'd traffic to the webserver post-inspection of the http traffic) for quite some time.

Not only does it work very well for microsoft and non-microsoft webservers (and perform application-layer inspection of a number of other protocols), but neither ISA 2004 nor ISA 2006 has had a single exploit in the wild (Don't believe me? Check secunia.com). ISA also sits in between most of the higher layers of the windows networking stack and the network itself.

ISA even supports pre-authentication for sites published like this - ISA 2006 even extends form-based auth (with cookies) to this for sites other than Outlook Web Access (Exchange's webmail interface). It'll also publish multiple sites (say, your /sharepoint, your /cacti, your /owa, and your /intranet sites) using path rules on the same IP address - one point of entry (or multiple points, with an array of ISA boxes), with a collection of disparate apps in your WAN / DMZ behind it.

As an aside, mod_security plus the reverse proxy capability in Apache 2 does precisely this too - with a little webmin love, a reverse proxy SSL offloading / inline web inspection linux distribution based on a very lightweight version of debian or redhat would be extremely easy - has anyone done anything prepackaged already, or thought about doing such?

Re:Microsoft ISA Server

[Anonymous Coward]

Nu vulnerabilities in ISA 2004 ?
One quick google and http://nvd.nist.gov/nvd.cfm?cvename=CVE-2006-7027

Re:Microsoft ISA Server

[jafiwam]

Yeah, except if you try to authenticate through it, it rebroadcasts the session and screws up a WebDav login.

Only solution, put in a complete bypass. Bypass so you can login. Great security that.

Re:Microsoft ISA Server

[Anonymous Coward]

"As an aside, mod_security plus the reverse proxy capability in Apache 2 does precisely this too"

mod_security is not needed. Apache 2 (Or any other apache in the last 6 years) does this just fine with mod_proxy and mod_ssl.

A SSL reverse proxy (which is not what this article is talking about btw), is hardly a new concept. Netscape Server 2/3 has this capability something like 8 years ago.

Re:Microsoft ISA Server

[Anonymous Coward]

Note that Microsoft don't consider that vuln a security issue. Only the author does.

I invite anyone to demonstrate to me how one might actually exploit it.

Whiskey Tango Foxtrot?

[ewhac]

...some WAN optimization gear can terminate the SSL sessions, shrink the traffic, and re-encrypt it for the next leg of the trip.

Um... Isn't that the very definition of a man-in-the-middle attack?

Er, no. Thank you very much for your kind offer, but I would prefer my encrypted data were not "optimized" in this way.

Schwab

Re:Whiskey Tango Foxtrot?

[Professor_UNIX]

Er, no. Thank you very much for your kind offer, but I would prefer my encrypted data were not "optimized" in this way.

Thanks to Enron, many people don't have a choice in the matter anymore. Allowing encrypted connections out of your LAN without scanning the data included could open you up to law suits or criminal prosecution now. Expect that SSL termination will be a growing trend in the years to come as more and more companies come on board.

Re:Whiskey Tango Foxtrot?

[Anonymous Coward]

Um... Isn't that the very definition of a man-in-the-middle attack?

Er, no. Thank you very much for your kind offer, but I would prefer my encrypted data were not "optimized" in this way.

If you manage your network infrastructure devices and servers properly, this is no more risky than simply adding more webservers to your DMZ.

In fact, it probably makes your infrastructure as a whole more resilient, since your webservers are no longer directly receiving traffic from clients, and data can be sanity checked, screened, etc, before it touches your webservers, reducing your overall attack profile.

I'm sure glad I don't have you managing my network infrastructure - sounds like you rely just a little too much on your 'jump to conclusions mat'

Re:Whiskey Tango Foxtrot?

[Melkman]

If you are a network admin SSL traffic is a bitch. Normal web traffic can be scanned for malicious content with ICAP. With SSL traffic you're out of luck. Also a lot of remote access programs tunnel their traffic in an SSL connection over port 443 (cool service LogMeIn, NOT). That means if you allow encrypted web traffic you also allow people on the network to give control over their PC's to external people. I've dealed with both. Some moron downloaded an infected program of an https site, which was luckily caught by the local virus scanner. And some nitwit called the helpdesk of an ASP which took over teir desktop while he was having sensitive data on his screen. After these events we enabled SSL termination on the proxies and feed all SSL traffic to the ICAP scanner and disallow any traffic that doesn't strictly follow HTTP. If someone has traffic that must bypass these rules the can request an exception, usually this concerns shitty java applications.
that was about a year ago. We were already using Bluecoat proxies, formerly known as CacheFlow.

Re:Whiskey Tango Foxtrot?

[Anonymous Coward]

It is a MITM. But I hate burst your bubble, but the majority of large ecommerce presences terminate SSL at hardware level appliances(SSL offloaders) and usually don't reencrypt it to the server.

Re:Whiskey Tango Foxtrot?

[starfishsystems]

Um... Isn't that the very definition of a man-in-the-middle attack?

Good point.

It's not an attack but it is definitely man-in-the-middle. A server proxy could make good architectural sense, for example when the SSL proxy is a load balancer in front of a server farm. As the client, you can validate that the load balancer is what its certificate claims it to be, say www.foo.com.

What is privately architected beyond that, you don't know, and really shouldn't care. Just think of the whole thing as one big metaserver whose identity has been established, and not much else. That's all you can assume anyway, right?

Note that the proxy can only succeed at representing itself as having the expected identity because it has been configured with the private key corresponding to that certificate and its identity. In other words, no random person can set up this man-in-the-middle. It opens no more of a vector for attack than root access to a plain old webserver would confer.

In fact, for those who advocate functional separation as a way to improve security, it has the same advantages that a firewall appliance has over managing a firewall local to each server. The firewall is not made vulnerable by defects in server software, and vice versa.

Re:Whiskey Tango Foxtrot?

[Anonymous Coward]

This is different than "simply adding more webservers". When I add more servers to farm, they are secured in my data center. I also terminate the single SSL Cert on a load balancer in the same data center so that the key actually exists in a single location. Distributing the private key to the edge and storing the contents unencrypted on a disk (in obfuscated chunks) is a bad idea.

Re:Whiskey Tango Foxtrot?

[Anonymous Coward]

Yup! and my unencrypted traffic travels a whole 25 feet to my rack that has the servers. I have reasonable confidence of the security of that length in my secured cage. If needed, I can always decrypt at the appliance, check to make sure its clean, and then encrypt it again before heading over the server also.

Re:Whiskey Tango Foxtrot?

[UnderCoverPenguin]

Note that the proxy can only succeed at representing itself as having the expected identity because it has been configured with the private key corresponding to that certificate and its identity. In other words, no random person can set up this man-in-the-middle.

Mostly true. Be aware that in a corporate environment, the IT department can install its own SSL CA certificates into the web browsers (and other applications). Once this is done, corporate proxy can masquerade as any entity the IT department chooses - up to and including auto-generation of SSL certificates, signed, of course, with the IT department's CA certificate.

This, of course, is no surprize.

Also, I assume that applications, including web browsers, could be configured to use a central CA certificate store, therefore, simplifying the task of seeding the applications' certificate stores.

What would be worrying is if there are proxy appliances (whether actual boxes or software appliances) that can do this without the need for seeding the browser certificate store. This would be possible if, for example, the appliance contained copies of the CA certificates used by the certificate vendors.

I suppose Verisign (or other certificate issuer) could market such appliances, but wouldn't they be opening themselves up to lawsuits in the event one (or more) of their CA certificates were to "escape"?

Re:Whiskey Tango Foxtrot?

[IchBinEinPenguin]

Thanks to Enron ... Expect that SSL termination will be a growing trend in the years to come as more and more companies come on board.

Which, like most 'security' measures, is a great way to keep honest people honest.
But then, I guess, it's not about stopping the bad behaviour, it's about being able to deflect lawsuits by being able to prove that you put measure in place, however ineffective, to try to stop it.

Re:Whiskey Tango Foxtrot?

[Sloppy]

Some moron downloaded an infected program of an https site, which was luckily caught by the local virus scanner.

Which just goes to show that the approach of attempting to detect malware (as opposed to preventing it from being run, or running it harmlessly in a sandbox, etc) is a fundamentally wrong approach to malware. I'm glad that you saw the local scanner's success as "lucky" because luck is exactly what it is.

Re:Whiskey Tango Foxtrot?

[starfishsystems]

Once this is done, corporate proxy can masquerade as any entity the IT department chooses

We have to be careful when talking about certificate identity. It's not the case that a proxy can ever "masquerade" as something else. By being configured with a given certificate and -- critically -- its corresponding private key, that proxy in identity terms becomes that other entity. As you say, this should be no surprise, but this is not familiar territory for many people, and it bears emphasis.

Often people mistakenly think that simply copying and installing a certificate onto a device will give it a new identity. That's due in large part to our careless use of language. Not only the certificate but also the private key must be installed. In any competent organization that private key is closely guarded. Even more closely guarded is the CA infrastructure used to bind certificates to private keys by means of a separate authority.

To return to the point I was making in my previous message, from a perspective outside a given organization, what is privately architected beyond a device it manages is something you strictly can't know and shouldn't care about. Think of it as one big metaserver whose identity has been established by virtue of the certificate identity. There is no purpose in speculating further.

You mentioned something about "seeding a certificate store". In a certificate infrastructure there is no certificate store and therefore no such process. For example, a client typically learn about a server certificate at the time the server itself presents it, not because it has to refer to a common public key store. This is the defining characteristic of digital certificates.

In practice, this presentation is likely to consist, not only of the server certificate, but of all the CA certs all the way up the chain to the root CA cert. All that a client needs to validate a previously unseen server certificate is therefore a trusted copy of the root certificate. This root cert is used to validate the uppermost CA cert in the chain, which can then be used to validate the next CA cert, and so on to the server certificate.

So indeed, a previously unseen proxy makes its presentation to a client just as any server does. However, I can't see that this constitutes any special reason for worry. Yes, a corrupt Certificate Authority could leak what we might call "counterfeit" certificate/private-key pairs. and those pairs could be misused in many ways. If that happens, effects on the proxy identity will be the least of your worries. All identities from that CA on downward are affected. It should be obvious that there is no effect in the upward direction.

Re:Whiskey Tango Foxtrot?

[Anonymous Coward]

Yeah. Try port 80 or 443 on my box. Think that's a web server? Think again. ...

I run sshd on port 80 and 443 so some network admin doesn't block me reaching my own box from almost anywhere.

mod 0P

[Anonymous Coward]

with any sort code sharing gains market share problem; a few don't be afraid Of user base for I'm =discussing guys are usually BSDI is also dead, your spare time Are the important I see the same gone Romeo and While the project and exciting; Uncover a story of bunch of gay negros they're gone Mac As one of the butts are exposed correct network Don't walk around getting together to It will be among

Don't trust SSL!

[gweihir]

The fact that this ''optimization'' is even possible, demonstrates that this protocol is insecure!

Use TLS and accept only the keys of the other endpoint or use a VPN or SSH in the first place.

Re:Don't trust SSL!

[modeless]

The protocol is not insecure; In order to enable the proxy to decrypt the SSL session, one of the endpoints must cooperate. It could work the same way with any of the protocols you mention.

Re:Don't trust SSL!

[gweihir]

True, but in VPN and SSH no endpoint will usually cooperate. With SSL this seems to be assumed as something that should be allowed, and possibly without telling the user. Bad, bad design IMO and a fundamental flaw.

Re:Don't trust SSL!

[hal9000(jr)]

Sure they if they are configured to do so. It;s not that hard and has been productied for years.

Nothing new, let's move along.

Re:Don't trust SSL!

[slamb]

The fact that this ''optimization'' is even possible, demonstrates that this protocol is insecure!

If they were able to do this without cooperation of the endpoints, it'd be a man-in-the-middle attack, and yes it would demonstrate that SSL is insecure.

The article's background information skips over an important point: the WAN accelerator device must be owned by the same group that runs the server. So this is for your data centers, not for your corporate headquarters.

I've never heard of this sort of device before, but I'll give my own background, filling in the gaps from their later information, my understanding of SSL, and a couple guesses.

The original (unencrypted) problem: Say you have a low-bandwidth link between a bunch of servers and clients. You want to make the best use of your link's limited bandwidth through compression (as well as QoS and such). In fact, you want to say "these next 426 bytes are the same as chunk 12345, which I've previously sent to some other client". The original setup looks like this:

Server <-slow-> Clients

The solution: obviously you can't say "just access chunk 12345" to client B if you sent chunk 12345 to client A. That's why they use a pair of these devices straddling the slow link to do this compression. They compress when sending and decompress when receiving. In the end, you still need to be able to send all the original bytes to each client. You might have many slow connections, but we'll say it's a "fast" link because in aggregate they're fast enough. So the setup looks like this:

Server <-raw/fast-> Accelerator.Server <-compressed/slow-> Accelerator.Client <-raw/fast-> Clients

Now, I'm not sure how common this setup actually is. Apparently you've cheaped out and gotten a T-1 or something across town, but you still have to pay for all the upstream bandwidth as the data leave your control or diverge. But let's just go with it.

Now add encryption. You could look for commonalities in the encrypted streams, but you're unlikely to find much. For the compression to be effective, it needs to work on unencrypted data. And you can't just forge a certificate on-the-fly to make proxying transparent, unless you've found a man-in-the-middle vulnerability in the SSL setup. Short of that, this is possible under one of two conditions: (1) the validators trust a CA certificate to which the device has a private key, so it can issue new certificates on the fly, or (2) the device has been preloaded with keys for every certificate it is expected to proxy.

The choice they've made seems to be this: you're assumed to control the servers but not the clients. So if you want to have an SSL connection to a given server, you need to load that server's key somewhere onto this pair of devices. (Preferably the Accelerator.Server for security.) That's what they're talking about in this paragraph:

In any SSL proxying architecture, the server must give up its certificates to at least one other device. In the cases of Blue Coat, Certeon and Riverbed, that device is a WAN optimizer that sits inside the data center where it is as physically secure as the server itself. ...

I'm not sure if they support SSL client authentication, but if they did, the choice is the same: load all the clients' keys onto the device or have your servers trust the device's CA.

Re:Don't trust SSL!

[Beryllium Sphere(tm)]

Yes, but that cooperation may not be the result of informed consent. It's painfully easy for an untrusted application to stick a new root CA into IE's list, after which it can sign its own certificates and use them to intercept SSL. MarketScore, reportedly, did this.

Re:Don't trust SSL!

[modeless]

You have a good point. Also, organizations that pre-load their own root certs on their computers get the power to intercept SSL connections made from those computers. I never really thought about it before, but that means if I'm doing online banking at work, the IT department could read it all. Theoretically.

Re:Don't trust SSL!

[modeless]

There are really no foolproof solutions; SSL's users can't judge the authenticity of certificates so asking them to verify anything isn't an option. Usable yet bulletproof security is still an unreachable holy grail. But I'd like to point out that you can still trust your SSL connection to Amazon as long as you really do trust all the people with certs in your trusted root list.

And I'd also like to point out that unless you manually verify the SSH keys using a seperate secure channel during your first connection to a host, SSH is vulnerable to attack at that time. Sure, SSH tells you you're insecure, but when you ignore it that doesn't help anything. And I'll wager *very* few people actually check their SSH keys properly.

SSL enables you to securely connect to anyone with a cert you trust on a moment's notice without a separate secure channel to enable key exchange; SSH doesn't replace that and neither do VPNs.

Re:Don't trust SSL!

[jsm300]

Yes, but this would be illegal (which might not stop them). Companies may have the right to monitor all traffic on their networks, read email, etc. They also certainly have the right to block all traffic to your bank. But for them to read your online banking transactions it would require them to forge your banks SSL certificate (i.e. they would need to create a certificate that claims it belongs to your bank, but they would sign it with the companies pre-loaded root cert). IANAL, but I'm fairly certain that would constitute fraud and would be actionable.

Re:Don't trust SSL!

[Tony Hoyle]

The whole point of these devices is that *don't* need to forge the bank's SSL certificate - they're breaking the end to end nature of SSL and inserting a proxy inbetween that allows the admins to get at the banking data in plaintext.

You have no way of verifying it because the ability to verify the SSL certificate is taken away from you (every site returns the certificate of the proxy).

Yes reading such data would be actionable - as would reading most emails without explicit written consent. Hasn't stopped them in the past and won't stop them in the future. If you *really* trust those admins then go ahead and use SSL sites at work, otherwise don't bother because it's not secure anymore.

Re:Don't trust SSL!

[it073281]

If you not trust SSL, how you keep security trade through SSL?

huh?

[Doppler00]

"some WAN optimization gear can terminate the SSL sessions, shrink the traffic and re-encrypt it for the next leg of the trip."

Doesn't this completely defeat the point of SSL? An encrypted link from client to server? If you got to an SSL website through this WAN link, it's not going to be encrypted anymore unless you trust the keys from the WAN access point. So, unless each WAN has it's own trusted key through a signature authority this isn't going to work. Seems pretty stupid to me. Isn't SSL traffic already compressed as part of the encryption procedure like PGP does?

Re:huh?

[flyingfsck]

It only works if your user name is Administrator and your password is 123... ;) This kind of proxy equipment needs the end points to co-operate. It cannot be done on just any ssh or stunnel connection. I don't really see the use for it. If your SSL connection is slow, then you have to adjust the cypher or something.

Re:huh?

[Anonymous Coward]

I work for one of the companies that make these devices. The point of SSL optimization isn't about the encryption speed, it's that the devices need to have a clear view on the traffic in order to optimize it.

Re:huh?

[rviana]

Imagine that you have 4000 branches all around the world. And imagine that the average latency across these links range from 10ms when its close, to over 400ms when its far. If you've ever tried to load a website with 30+ images/javascript/css with IE's measly 2 http simultaneous connections. ONLY then, will you realize how necessary this is. Because its either WAN optimization (more for latency reduction...not so much for bandwidth reduction), or local servers in 4000 branches.

Now throw in a little CIFS acceleration (ms exchange, or file sharing), or a little http caching, and you have a USD$2500 device that's worth its weight in gold. Namely due to reduction in local servers/backups, and a huge reduction in customer *slowness* complaints. Unfortunately, when your primary business is not application development, you have very little choice among which applications you can run across your WAN.

What about the SSL latency?

[Anonymous Coward]

SSL adds 200ms latency as compared to not using any encryption.
Is there a way to reduce the SSL latency?

Re:What about the SSL latency?

[jmauro]

Don't use SSL. Encryption and Decryption take time, there's nothing that can be done about it.

Re:What about the SSL latency?

[Beryllium Sphere(tm)]

Nothing? Buy a crypto accelerator from nCipher or any other company that sells them. AES in smart implementations is in the neighborhood of 16 cycles per byte anyway.

Nothing can be trusted...

[antirelic]

Its a good thing that these devices can offer SSL, but it should only be talked about as "additional" security measures. There seems to be a trend in the IT world where one "new" security tool comes along and renders some "other" (other, not older) security tool/method discarded. These lessons have been learned, and shouldnt be repeated: Defense in Depth.

Re:Nothing can be trusted...

[Anonymous Coward]

That's why I run ssh over stunnel on openvpn over ipsec with each layer running in a different vmware environment in order to connect to my server which is connected directly via fiber-optic and is only two meters away. Also both my client and server are in a steel cage in a steel reinforced cube at the bottom of the ocean burried in silt with a thick blanket of nuclear waste on top. And still I doubt if my furry porn is safe.

This is gross irresponsibility

[Animats]

Any administrator who puts in a security hole like that to get a minor reduction in bandwidth is grossly irresponsible. No device in the middle of the network should have the end to end decryption keys. Ever.

If you have too much traffic to your secure servers, take a look at what they're sending. Maybe the canned images can be moved to a non-secure server, where they can be cached locally. You're probably not actually sending huge volumes of secure data to a browser.

Or maybe you just need to find out who's downloading videos and stop them.

Re:This is gross irresponsibility

[hab136]

SSL is used for more than just browsers. Many business data feeds are XML over HTTP over SSL (I've seen this in growing use at financial institutions). Many oddball applications took their standard protocol and wrapped it in SSL because their clients demanded it.

Re:This is gross irresponsibility

[UnderCoverPenguin]

If you have too much traffic to your secure servers, take a look at what they're sending. Maybe the canned images can be moved to a non-secure server

In theory, this sounds good, however, many browsers put up a warning when a web page contains mixed "secure" and "unsecure" content. (I just checked this with FireFox 2.0.0.2 with a page on my internal server; I got such a warning.)

I hope such warnings will continue to be the default. As such, the work around is either reduce the number and size of images in your web page, and/or use SSL/TSL acceleration.

Re:This is gross irresponsibility

[VENONA]

Not sure what you meant by, "the middle of the network." A decent network design will likely have all of this happening on the DMZ. One positive thing about doing things this way (in addition to optimizing WAN traffic) would be that endpointing before the host allows you to place a network intrusion sensor on the wire.

If you have to comply with policies that require NIDS & retention of their logs, you don't have any other good option that won't load the host. That load will be disk I/O and it's associated CPU cost, or quite a bit more CPU and network I/O, if you're logging (possibly encrypting again) to a remote log host.

Depending upon exactly how your DMZ is configured (and what regs/policies are involved, how carefully you control access, etc.), you might not even need to re-encrypt between the appliance and the host, which could shrink host CPU SSL overhead to nothing.

As usual, it all depends upon the specific environment.

Legality

[digitalgimpus]

As I recall it's criminal to intercept financial communications without permission from the institution.

That means, if an employee at a company that uses a BlueCoat device were to say login to a bank... the sysadmin would technically be violating the law.... unless the bank gave explicit permission (most likely would need to be in writing).

Even if you were to ban online banking in the workplace, that wouldn't change the impact on the sysadmin's libility if a user broke the rules. Go ahead, fire the employee... they just let the bank know about the security breach, and who the "hacker" was.

Seems to me like the laws may need some adjusting.

And that's why I don't login to a bank from work. I know sysadmins in many companies steal SSN's, credit card #'s, etc. by using Timbuktu, VNC, etc. as well as sniffing packets. It's just what it is. Why should I put my identity at risk? I don't see a good reason. I wait until I'm home for that. It's one thing to read an email, it's another to jack by SSN.

Re:Legality

[Anonymous Coward]

I work for one of the companies mentioned in the article, and I think that the /. posters here don't realize that one needs one of these devices at each end of the WAN. One to perform its magic, and one to undo the magic. All optimized traffic between them is within the organization. So, your session with your bank or home PC or whatever would not be looked at by a WAN accelerator, since internet hosts (as opposed to the company's WAN hosts) would get routed as passthrough only. So if you are worried about someone snooping the encrpyted SAP connection you have to your datacenter, fine, but it you are worried about someone snooping your https purchase at Amazon, you needn't worry.

Right, what these devices actually do.

[Anonymous Coward]

You do realise it's simply not possible for ISPs to screw with SSL traffic? That's the whole point of this.

These products aren't used for Internet connections. They're used for either dedicated WAN links or for VPN links. Say you have an office out in timbucktoo and a head office. You put one of these on/instead of the the gateway router at the head office, and another at the same gateway at the branch (just inside your network) so all your traffic is going through them. (And these devices are designed to help get the best out of that private frame relay link you've got as well as VPNs.)

What do they do? They automatically cache repeated TCP traffic patterns against all traffic sent to and from the head office. (Basically a matched pair - when one end sends a particular packet the pair of devices has seen before, just the reference to that pattern is sent. Yes, they have to keep in synch and all that.)

See what that gets you. Transparent caching of all interal web browsing. FTP downloads. Transparent caching of file share traffic. IMAP traffic. (Imagine if you send the same 100 kb word attachment to every end user. Now imagine it only gets sent once, without any software seeing anything but normal, ordinary, IMAP.) It just recognises patterns in the TCP traffic, not caring what those patters actually represent. (Lower latency too - because that 100 kb word doc comes out of cache rather than across the line.)

Now SSL disables all this. Each SSL session is unique - the data patterns are low entrophy nearly random noise, from the point of view of these devices. The patterns are never repeated, and thus you don't get to cache anything.

You DO have the option, of course, doing a man-in-the-middle-attack, where you decrypt the traffic on the device, subject that to caching, and re-encrypt it once it leaves the other matched device (presumably the WAN-accelerator-to-WAN-accelrator link is also encrypted.).

BUT ISPs cannot do this. To pull off that M-i-t-m, they have two ways: [1] to screw around with your SSL system's root certificates. Corporates can do this, just deploy their own "trusted" CA. Piece of cake. ISPs can't. [2] Have the private keys for the destination server loaded into the device. Again, Corporates can (sometimes). Edge SSL applicance owned by the same organsiation as the end server can. ISPs, again, can't.

These devices are aimed at corporates, where the network and end-points are all owned by the company. Of course, if the wan-accelerator-to-wan-accelerator link isn't encrypted then you have an issue (can you trust the device designers? That's the POINT of this article!) If that fake CA private key got out, you've also got real issues too!

Re:Right, what these devices actually do.

[TheLink]

Actually in theory your ISP could supply you with a fake root cert. Unless you do stuff like downloading your browser using a different ISP or a different channel, or compare notes with someone who has.

Re:Right, what these devices actually do.

[Anonymous Coward]

No, in theory they could not unless they put the fake root cert as a "trusted CA" in your OS configuration.

Re:Right, what these devices actually do.

[petermgreen]

they could do that and they could also use the nasty flaw in IE that allows owners of versign certs to MITM ssl connections made by it provided you own a verisign issued certificate.

but people who share thier connections with broadband routers who plug in a PC with firefox already installed will not have any reason to run the ISPs software and hence will notice this and there isn't really anything they can do about it.

and it would only require one sufficiantly tech savy user using a browser that didn't have thier root cert and wasn't vulnerable to the exploit to spot what they were doing and out them and it could mean very bad press especially if the banks found out and started telling thier customers not to use said isp.

Apache has done this for a while...

[SuperBanana]

It'll also publish multiple sites (say, your /sharepoint, your /cacti, your /owa, and your /intranet sites) using path rules on the same IP address - one point of entry (or multiple points, with an array of ISA boxes), with a collection of disparate apps in your WAN / DMZ behind it

In other words, something Apache has done for more than half a decade?

Re:Apache has done this for a while...

[beuges]

Apache is a web server, ISA is a gateway server. The proper comparison would be apache to IIS, which has also done this for half a decade, if not longer.

Why is this even a feature

[Anonymous Coward]

net-to-net VPN is what any sane person would use for a WAN

Why is this news?

[todd3091]

I don't understand why this is being portrayed as something "new" to IT. I work for a medium sized company, and we have been doing this for nearly 5 years. There are a slew of vendors in this space including F5 Networks, Citrix, Sun, and Microsoft. The technology works be installing the SSL certificate onto the appliance rather than the server. If designed correctly, this is no less secure than the conventional model, and can save significant processing load on web servers.

Not sure about over the WAN..

[_hAZE_]

I've actually been around SSL Accelerators for a few years now, working in the web hosting industry. The idea is pretty much the same; your customers connect to your website using https, except they're actually talking to an SSL Accelerator/load balancer device, not the actual web server. The SSL Accelerator holds the SSL certificate, decrypts the traffic, and sends it to the web server in plain text. The web server replies back in plain text, the SSL Accelerator encrypts it, and send it back to the customer's web browser. Being a device made specifically to handle this type of traffic, the SSL Accelerator can encrypt/decrypt a lot faster than the web server, leaving the web server to do it's task of serving up content without all the overhead involved with SSL.

Normally, the SSL Accelerators are in very close proximity to the web servers (both network and physical distance-wise). The thought of doing something similar with enterprise WAN traffic over long distances, however, is a bit more frightening. I guess like many other things out there, it all depends on who your vendors are and how you implement the solution. Just be careful.. the Internet can be a nasty place.

SSL-from a sales guy

[Anonymous Coward]

Depends on who you choose as a vendor, how your org is using the technology and where in the network you implement the protocol/system. cisco is too easy to hack (Cisco security is too common and based on shitty code), but juniper and a few others have pretty good products in this space. The bottom line is- if it is plugged in, it is vunerable. Its really all about making it too difficult for some wannabe high school black hat to access sensitive data. SSL is great for remote workers (ie sales and such), as long as the system used is ASIC based or has the processing power to handle the encrypt/decrypt. From a administration perspective it is a godsend as there are no clients to load, patch and monitor. As this technology has been out for a few years, I am sure there are emerging technologies to replace this, but from a users perspective (and from most IT Dir's POV) this alleviates a great deal of complexity for non-power users and at the same time makes remote access easier to manage.

As a sales guy (former network eng), I find it amazing how many people have the wrong perception and are unwilling to listen to others. Black, grey and white hat-it is easy to tell IMMEDIATELY who knows their shit and who just talks it, just like the guy I just sold a GBIC to for his Avian over IP layer 3 switch.

great

[Anonymous Coward]

The concept is just awesome. Please read the mechanisms and search ssl wan acceleration and do research. great work by some of these companies

Cheap(ish) Appliance ?

[Anonymous Coward]

Anyone have familiarity or an opinion on with working with Kemper Technologies' LoadMaster devices for this? http://www.kemptechnologies.com/load-balancer-1500 .shtml Looking to do incorporate something like this for my site, but to fork over 4g to nCipher for a replacement NIC seems a bit nuts for a non-commerce app.

always adjust your password

[it073281]

If your SSL connection is slow, you better always adjust your password.

to keep your connection security.

SSL

[june_c21]

Areas of concern that SSL addresses: 1. Unauthorised access to cached data at each access point Problems that SSL poses: 1. Slower throughput due to encryption process