Re: [cryptography] if MitM via sub-CA is going on, need a name-and-shame catalog (Re: really sub-CAs for MitM deep packet inspectors?)
On 2011-12-02 03:18, Adam Back wrote: [Other aspects of Adam's post elided to be addressed in a different context. My response here focuses exclusively on the very narrow question of corporate MITM SSL proxies] > 2. corporate LAN SSL MitM (at least the corporation has probably a contract > with all users of the LAN waiving their privacy). Probably even then its > illegal re expectation of privacy in workplace in most contexts in US & > Europe. [...] > Obviously the most interesting ones are 3 & 4. But Peter says he has > evidence 2 (LAN mitm) is going on in the name of deep packet inspection I > guess in corporate LANs and that itself employees should be aware of that. I can't speak to European workplace regulations. Here in the U.S. it is common practice for enterprise environments to employ both inbound and outbound content inspection and filtering, including DLP and extrusion prevention. Those enterprises that do and even most corporate environments that don't will typically have a corporate CA root that automatically gets pushed out via Active Directory to the standard in-house Windows OS distribution. That in-house CA may or may not chain to a public CA. Whether or not such chaining takes place is irrelevant for content-inspection purposes, since the resultant ephemeral destination site SSL server certs are only ever seen in-house. (This is for example how your standard in-house Blue Coat installation works). Note however that there are many reasons why an enterprise may push an in-house root or sub-CA to the desktop that have nothing to do with anybody intercepting content. --Lucky Green ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] if MitM via sub-CA is going on, need a name-and-shame catalog (Re: really sub-CAs for MitM deep packet inspectors?)
ianG writes: >PS; we need a better name than DPI MITM. For some reason I'm thinking of WITM. Given that the whole reason for doing this silly-walk in the first place was to protect us against MITMs, I wouldn't use WITM, I'd call it a WTFITM. Peter. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] if MitM via sub-CA is going on, need a name-and-shame catalog (Re: really sub-CAs for MitM deep packet inspectors?)
Wifebeating syndrome :) I was aware of the claim of MITMing, but nobody offered proof and it sort of faded away under the cover of NDAs. Just on that above: Back in 2005, 2006 or so when the Mozilla policy was being written, allegations surfaced that two CAs were practicing MITMing as a business model. From what I recall of the discussion, the business model as suggested bears an uncanny resemblance to DPI, 'cepting the data was on-sold. Surprise surprise, the audit criteria of the time did not exclude this, and as long as you declared it in your CPS, you were on the safe but dirty side of some line somewhere. However, no proof was forthcoming, and the offensive security-by-NDA trick worked again, with a nod to Dan. On 3/12/11 20:30 PM, Peter Gutmann wrote: You do need to distinguish between CAs issuing sub-CA certs (not for MITM but for businesses who need them) and DPI MITM certs. It's the sub-CA certs that have been around for a decade or more, the MITM certs are a lot newer, and I'm not sure that the CAs know if, or that, they're being used for this. Ah ok, yes. The issue of sub-CAs and external RAs has been widely discussed in Mozilla's public forum. For example a legitimate reason for having a sub-CA is that you want to secure your servers but don't want to reveal to a third party your entire internal corporate infrastructure. So you buy a sub-CA cert and issue your own internal-use-only certs off it, and you don't have to tell anyone what you're doing. Or you may need 10,000 different certs a year every year and it's not possible to do that via an interface designed for one cert at a time, so you need to run your own CA to handle the volume and diversity. A variation of this is that you act as an RA for the public CA, so you forward gimme-a-cert requests on to the public CA with the understanding that you've checked that they're legit. That Comodo reseller that got compromised seems to have been one of these, except that they sold to the public rather than being for corporate-internal-use only. There's a million reasons why you'd need to do this sort of thing, and most of them are legitimate business needs, so it's not as if this is some arbitrary ill-considered decision, it meets a legitimate need. The problem is caused (again) by the browser PKI model, if you don't have your cert chaining to one of a small set of browser-vendor-blessed CAs then you've DoSed your own servers/sites/whatever, however you may not be in a position to buy certs from public CAs, so the solution is to buy the CA capabilities that allow you to deal with this yourself. Following conventional PKI thinking, should you misbehave (certs for google.com suddenly turn up issued by your sub-CA) then your sub-CA cert gets revoked, you lose your 5-6 digit license fee, and possibly the CA gets to beat you over the head with lawyers. So there's really no problem. Oh, except for the fact that revocation doesn't work and in any case no-one checks to see what you're up to. But on paper everything's OK. As I understand it at the moment, the new Baseline Requirements has established the firm rule that whatever is done with these things, the CA is fully responsible and the Auditor rules over the entire hierarchy [0]. (I for one am mollified. Others remain less so.) So I'd rewrite the above last part to say, and your CA gets dropped from the root list of major vendors. What is the earliest sighting of a DPI-inspired MITM cert? iang PS; we need a better name than DPI MITM. For some reason I'm thinking of WITM. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] if MitM via sub-CA is going on, need a name-and-shame catalog (Re: really sub-CAs for MitM deep packet inspectors?)
ianG writes: >Wifebeating syndrome :) I was aware of the claim of MITMing, but nobody >offered proof and it sort of faded away under the cover of NDAs. You do need to distinguish between CAs issuing sub-CA certs (not for MITM but for businesses who need them) and DPI MITM certs. It's the sub-CA certs that have been around for a decade or more, the MITM certs are a lot newer, and I'm not sure that the CAs know if, or that, they're being used for this. For example a legitimate reason for having a sub-CA is that you want to secure your servers but don't want to reveal to a third party your entire internal corporate infrastructure. So you buy a sub-CA cert and issue your own internal-use-only certs off it, and you don't have to tell anyone what you're doing. Or you may need 10,000 different certs a year every year and it's not possible to do that via an interface designed for one cert at a time, so you need to run your own CA to handle the volume and diversity. A variation of this is that you act as an RA for the public CA, so you forward gimme-a-cert requests on to the public CA with the understanding that you've checked that they're legit. That Comodo reseller that got compromised seems to have been one of these, except that they sold to the public rather than being for corporate-internal-use only. There's a million reasons why you'd need to do this sort of thing, and most of them are legitimate business needs, so it's not as if this is some arbitrary ill-considered decision, it meets a legitimate need. The problem is caused (again) by the browser PKI model, if you don't have your cert chaining to one of a small set of browser-vendor-blessed CAs then you've DoSed your own servers/sites/whatever, however you may not be in a position to buy certs from public CAs, so the solution is to buy the CA capabilities that allow you to deal with this yourself. Following conventional PKI thinking, should you misbehave (certs for google.com suddenly turn up issued by your sub-CA) then your sub-CA cert gets revoked, you lose your 5-6 digit license fee, and possibly the CA gets to beat you over the head with lawyers. So there's really no problem. Oh, except for the fact that revocation doesn't work and in any case no-one checks to see what you're up to. But on paper everything's OK. Peter. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] if MitM via sub-CA is going on, need a name-and-shame catalog (Re: really sub-CAs for MitM deep packet inspectors?)
> Whoever said security by obscurity doesn't work? Must have been > on something. Obscurity works for the offense. --dan ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] if MitM via sub-CA is going on, need a name-and-shame catalog (Re: really sub-CAs for MitM deep packet inspectors?)
> On 3/12/11 03:36 AM, Ben Laurie wrote: >> On Fri, Dec 2, 2011 at 4:14 PM, ianG wrote: >>> On 2/12/11 23:00 PM, Peter Gutmann wrote: I guess if you're running into this sort of thing for the first time then you'd be out for blood, but if you've been aware of this it going on for more than a decade then it's just business as usual for commercial PKI. I'm completely unfazed by it, it's pretty much what you'd expect. >>> >>> Wifebeating syndrome :) I was aware of the claim of MITMing, but nobody >>> offered proof and it sort of faded away under the cover of NDAs. >> Note that this is still the case :-) > > Which is the point of security by NDA :) > > Whoever said security by obscurity doesn't work? Must have been true :) ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] if MitM via sub-CA is going on, need a name-and-shame catalog (Re: really sub-CAs for MitM deep packet inspectors?)
That vast numbers of private label CAs exist that could perform man in the middle attacks is disturbing, but not newsworthy. That some pseudonymous guy on the internet says that they do perform man in the middle attacks is disturbing, but not newsworthy. Proof of a man in the middle attack, in the form of a certificate chain wherein a private label ca issues a certificate for an outside domain name, would be newsworthy, would be a big step towards replacing PKI. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] if MitM via sub-CA is going on, need a name-and-shame catalog (Re: really sub-CAs for MitM deep packet inspectors?)
On Fri, Dec 2, 2011 at 2:00 PM, ianG wrote: > On 3/12/11 03:36 AM, Ben Laurie wrote: >> >> On Fri, Dec 2, 2011 at 4:14 PM, ianG wrote: >>> >>> On 2/12/11 23:00 PM, Peter Gutmann wrote: I guess if you're running into this sort of thing for the first time then you'd be out for blood, but if you've been aware of this it going on for more than a decade then it's just business as usual for commercial PKI. I'm completely unfazed by it, it's pretty much what you'd expect. >>> >>> >>> Wifebeating syndrome :) I was aware of the claim of MITMing, but nobody >>> offered proof and it sort of faded away under the cover of NDAs. >> >> Note that this is still the case :-) > > > Which is the point of security by NDA :) > > Whoever said security by obscurity doesn't work? Must have been on > something. :) ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] if MitM via sub-CA is going on, need a name-and-shame catalog (Re: really sub-CAs for MitM deep packet inspectors?)
On 3/12/11 03:36 AM, Ben Laurie wrote: On Fri, Dec 2, 2011 at 4:14 PM, ianG wrote: On 2/12/11 23:00 PM, Peter Gutmann wrote: I guess if you're running into this sort of thing for the first time then you'd be out for blood, but if you've been aware of this it going on for more than a decade then it's just business as usual for commercial PKI. I'm completely unfazed by it, it's pretty much what you'd expect. Wifebeating syndrome :) I was aware of the claim of MITMing, but nobody offered proof and it sort of faded away under the cover of NDAs. Note that this is still the case :-) Which is the point of security by NDA :) Whoever said security by obscurity doesn't work? Must have been on something. iang ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] if MitM via sub-CA is going on, need a name-and-shame catalog (Re: really sub-CAs for MitM deep packet inspectors?)
Some random chiming in... On 2011 Dec 2, at 5:00 , Adam Back wrote: > On Sat, Dec 03, 2011 at 01:00:14AM +1300, Peter Gutmann wrote: >> I was asked not to reveal details and I won't, > > Of course, I would do the same if so asked. But there are lots of people on > the list who have not obtained information indirectly, with confidentiality > assurances offered, and for them remailers exist. > >> but in any case I don't know whether it would achieve much. For the case >> of a public CA doing it, you'd see that CA X is involved, ... > > personally I'd like to know who is doing this and at what scale. As Peter said, this has been happening for some years. The reason I mentioned CDG airport is because it's the only such incident where I remembered exactly where I was (Sheraton hotel, never staying there again... not that this is the reason why). To me it was just the usual speed bump to be worked around. > >> I guess if you're running into this sort of thing for the first time then >> you'd be out for blood, but if you've been aware of this it going on for more >> than a decade then it's just business as usual for commercial PKI. I'm >> completely unfazed by it, it's pretty much what you'd expect. > > I do not think its what you'd expect. A CA should issue certificates only > to the holders of certificates. It should NOT issue sub-CA certifactes to > third parties who will then issue certs to domains they dont own. Not even > on the fly inside a "packet inspection" box. For how many years have Thawte and Verisign and others been prepared to issue certificates based only on the fact that the cheque cleared? > > If someone wants to inspect packets on a corporate lan they can issue their > own self-signed cert, and install that in their users browsers in their OS > install image. > > Then if I go on their LAN with my own equipment, I'll get a warning. > > I think its unacceptable to have CAs issuing such certs. I agree. But like a lot of unacceptable things, it happens because it makes money for someone. > >>> It breaks a clear expectation of security and privacy the user, even very >>> sophisitcated user, has about privacy of their communications. >> >> Not on a corporate LAN. IANAL but AFAIK your employer's allowed to run that >> in whatever way they want. > > No. Also IANAL but there were several cases where employees did have an > expectation of privacy upheld even in the US. Certainly you cant do that in > the EU legally either. So now the company uses a login banner that says "You have no expectation of privacy when using this system." And of course the employee has no choice but to click through. [rest snipped.] Greg. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] if MitM via sub-CA is going on, need a name-and-shame catalog (Re: really sub-CAs for MitM deep packet inspectors?)
On Fri, Dec 2, 2011 at 4:14 PM, ianG wrote: > On 2/12/11 23:00 PM, Peter Gutmann wrote: >> >> I guess if you're running into this sort of thing for the first time then >> you'd be out for blood, but if you've been aware of this it going on for >> more >> than a decade then it's just business as usual for commercial PKI. I'm >> completely unfazed by it, it's pretty much what you'd expect. > > > Wifebeating syndrome :) I was aware of the claim of MITMing, but nobody > offered proof and it sort of faded away under the cover of NDAs. Note that this is still the case :-) ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] if MitM via sub-CA is going on, need a name-and-shame catalog (Re: really sub-CAs for MitM deep packet inspectors?)
On 3/12/11 03:14 AM, ianG wrote: ... Except, *natural person* rights can't be *reliably* contracted away. oops, fix bloopers. wish we had time to be lawyers too... iang ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] if MitM via sub-CA is going on, need a name-and-shame catalog (Re: really sub-CAs for MitM deep packet inspectors?)
On 2/12/11 23:00 PM, Peter Gutmann wrote: I guess if you're running into this sort of thing for the first time then you'd be out for blood, but if you've been aware of this it going on for more than a decade then it's just business as usual for commercial PKI. I'm completely unfazed by it, it's pretty much what you'd expect. Wifebeating syndrome :) I was aware of the claim of MITMing, but nobody offered proof and it sort of faded away under the cover of NDAs. The problem here is that it breaks the CA/SSL promise - that there is no MITM. That is the reason for using certificates in the first place, over and above opportunistic encryption. That is the life-blood of SSL v2 - stop the MITM. If we've decided that the CAs have optioned out the MITM promise on a mass scale, then this breaks the promise. All they've done is sold on the MITMs. So we may as well go back to TOFU. It breaks a clear expectation of security and privacy the user, even very sophisitcated user, has about privacy of their communications. Not on a corporate LAN. IANAL but AFAIK your employer's allowed to run that in whatever way they want. Legally is one plane of dispute: Yes, sure, contractually and under agency theory, the employer is probably within rights. Except, rights can't be contracted away. Data protection commissioners might not agree, as they don't agree that video can be used in offices, only in corridors. And, they don't agree that your radio broadcast information can be recorded by google, in contradiction to international radio convention :) And they can read an MITM promise much like any other user. And legal counsel might be a bit pissed if you get phished and the court case points the finger at the in-house MITM. The game is not purely logical or contractual or controllable. And reputation adds a joker. I think employees just need to be aware that a corporate LAN is owned by your employer, and run for their benefit, not yours. If you want to do $non_work_related_whatever, do it from your home system. I don't think that is a reliable presumption any more. There have been numerous court cases that have trashed the simple "corporate assets" presumption. iang ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] if MitM via sub-CA is going on, need a name-and-shame catalog (Re: really sub-CAs for MitM deep packet inspectors?)
Adam Back writes: >I wonder what that even means. *.com issued by a sub-CA? that private key >is a massive risk if so! I wonder if a *.com is even valid according to >browsers. Or * that would be funny. No idea, but remember that it's not "general-purpose browsers", it's "cellphone browsers" that historically have been crufty little custom apps with who knows what behaviour. Also, the phone's entire worldview is what the cell site it's connected to wants it to be. For example if the telco wants to reactivate an expired cert they can just make it be 2006 again. Or block access to CRLs (do mobile browsers even check these?). Or return '3' in response to an OSCP query (assuming mobile browsers do OCSP). Peter. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] if MitM via sub-CA is going on, need a name-and-shame catalog (Re: really sub-CAs for MitM deep packet inspectors?)
I wonder what that even means. *.com issued by a sub-CA? that private key is a massive risk if so! I wonder if a *.com is even valid according to browsers. Or * that would be funny. Adam On Sat, Dec 03, 2011 at 02:24:53AM +1300, Peter Gutmann wrote: Adam Back writes: [WAP wildcard certs] That is bad. Are you saying there is anyone doing SSL mitm for stream compression reasons? Who? The use of wildard certs in WAP gateways came up from the SSL Observatory work... hmm, there's at least a mention of it in "An Observatory for the SSLiverse". Peter. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] if MitM via sub-CA is going on, need a name-and-shame catalog (Re: really sub-CAs for MitM deep packet inspectors?)
Adam Back writes: >[WAP wildcard certs] > >That is bad. Are you saying there is anyone doing SSL mitm for stream >compression reasons? Who? The use of wildard certs in WAP gateways came up from the SSL Observatory work... hmm, there's at least a mention of it in "An Observatory for the SSLiverse". Peter. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] if MitM via sub-CA is going on, need a name-and-shame catalog (Re: really sub-CAs for MitM deep packet inspectors?)
On Sat, Dec 03, 2011 at 01:00:14AM +1300, Peter Gutmann wrote: I was asked not to reveal details and I won't, Of course, I would do the same if so asked. But there are lots of people on the list who have not obtained information indirectly, with confidentiality assurances offered, and for them remailers exist. but in any case I don't know whether it would achieve much. For the case of a public CA doing it, you'd see that CA X is involved, ... personally I'd like to know who is doing this and at what scale. I guess if you're running into this sort of thing for the first time then you'd be out for blood, but if you've been aware of this it going on for more than a decade then it's just business as usual for commercial PKI. I'm completely unfazed by it, it's pretty much what you'd expect. I do not think its what you'd expect. A CA should issue certificates only to the holders of certificates. It should NOT issue sub-CA certifactes to third parties who will then issue certs to domains they dont own. Not even on the fly inside a "packet inspection" box. If someone wants to inspect packets on a corporate lan they can issue their own self-signed cert, and install that in their users browsers in their OS install image. Then if I go on their LAN with my own equipment, I'll get a warning. I think its unacceptable to have CAs issuing such certs. It breaks a clear expectation of security and privacy the user, even very sophisitcated user, has about privacy of their communications. Not on a corporate LAN. IANAL but AFAIK your employer's allowed to run that in whatever way they want. No. Also IANAL but there were several cases where employees did have an expectation of privacy upheld even in the US. Certainly you cant do that in the EU legally either. 3. public provider SSL MitM - if your ISP, wifi hotspot, 3g data prov, is doing this to you, paid or free, thats illegal IMO. Heads should roll up the CA tree. I think this is where we differ in our outlook. This (and yeah, I'd still like to see the certs for one of these from a public location :-) is business as usual for commercial PKI. I dont view this as business as usual. If I am on a public hotspot, 3g or my own DSL/cable I do ABSOLUTELY NOT expect the ISP to be getting inside my SSL connection to my bank, my gmail account etc. Whether I paid or not. For any reason at all (not to do advert analysis, not to do anti-virus, not to re-write pages etc). I use airport/hotel wifi a lot and I've never seen it and I am suspicious enough to use cert patrol etc. Remember the link to the SonicWall docs I posted a few days ago, http://www.sonicwall.com/downloads/SonicOS_Enhanced_5.6_DPI-SSL_Feature_Module.pdf? It's an advertised feature of the hardware (not just from SonicWall, other vendors do it too), d'you think people are going to buy that and then not make use of it? So you just build your defences around the fact that it's broken and then you won't run into problems. Well yes I know the hardware exists. I even helped design and implement a software-only MitM at ZKS. Before you get alarmed the cert it created was known only to the user, generated on the machine, and its purpose was to protect the user via a cookie manager protecting their privacy. If you read the sonic wall stuff its fairly clear the model that they talk about at least is that you do not have a sub-CA key. You generate a self-signed CA key, and install it in your corporate LAN browsers trusted CA dbs. Clearly it would also work with such a cert. Similarly their doco about server SSL shows they dont expect you to have a proper sub-CA key. (scenario where the web server for public access is behind the sonicwall) you are expected to import your server SSL certs mapped per IP address into the box. (Otherwise the public would see self-signed MitM notices when they browse the site. Or the sub-CA cert. Oh, another place where this happens is WAP gateways, where they MITM everything so they can rewrite the content to save bandwidth and make things work on mobile devices. So, is that bad, or good, or both, or neither? Well people were complaining about the "WAP gap" a long time ago. I thought this was more about the phones at the time being not CPU powerful enough to terminate SSL. The idea that a gap exists somewhere where your traffic is decrypted was viewed as a significant security limitation people were pleased to see go a way with phones fast enough to terminate their own SSL. That is bad. Are you saying there is anyone doing SSL mitm for stream compression reasons? Who? Adam ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] if MitM via sub-CA is going on, need a name-and-shame catalog (Re: really sub-CAs for MitM deep packet inspectors?)
Adam Back writes: >a public MitM proxy? Or a corporate LAN. Private organisation. >That intermediate CA needs publishing, and the CA that issued it. I was asked not to reveal details and I won't, but in any case I don't know whether it would achieve much. For the case of a public CA doing it, you'd see that CA X is involved, but since it's quite likely that CAs A...W and Y...Z are also at the party, all it'd do is focus people's ire on one entity. Also, if this is being done by a private organisation for DPI to secure their corporate LAN then they're probably quite within their rights to do it. I guess if you're running into this sort of thing for the first time then you'd be out for blood, but if you've been aware of this it going on for more than a decade then it's just business as usual for commercial PKI. I'm completely unfazed by it, it's pretty much what you'd expect. >It breaks a clear expectation of security and privacy the user, even very >sophisitcated user, has about privacy of their communications. Not on a corporate LAN. IANAL but AFAIK your employer's allowed to run that in whatever way they want. >1. private label sub-CA (where the holder has signed an agreement not to >issue certs for domains they do not own - I know its policy only, there is no >crypto enforced mechanism, but thats the same bar as the main CAs themselves). For the cases where I've been involved I wasn't aware of there being anything like this in the agreements (actually there probably was something somewhere, I didn't look through all the paperwork). I still have at least some of the documentation stored somewhere (NB: Not under NDA and with the agreement of the parties involved, it was an interesting case study on how these things work), if I ever manage to dig it up I'll see what the conditions were. In any case though it was honour-system security, if you really wanted to do bad things there weren't any controls that I could see to stop you. >3. public provider SSL MitM - if your ISP, wifi hotspot, 3g data prov, is >doing this to you, paid or free, thats illegal IMO. Heads should roll up the >CA tree. I think this is where we differ in our outlook. This (and yeah, I'd still like to see the certs for one of these from a public location :-) is business as usual for commercial PKI. Remember the link to the SonicWall docs I posted a few days ago, http://www.sonicwall.com/downloads/SonicOS_Enhanced_5.6_DPI-SSL_Feature_Module.pdf? It's an advertised feature of the hardware (not just from SonicWall, other vendors do it too), d'you think people are going to buy that and then not make use of it? So you just build your defences around the fact that it's broken and then you won't run into problems. Oh, another place where this happens is WAP gateways, where they MITM everything so they can rewrite the content to save bandwidth and make things work on mobile devices. So, is that bad, or good, or both, or neither? >I guess in corporate LANs and that itself employees should be aware of that. I think employees just need to be aware that a corporate LAN is owned by your employer, and run for their benefit, not yours. If you want to do $non_work_related_whatever, do it from your home system. Peter. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
