Hi Kyle, To make the story even shorter, in order to perform this MITM they use a wild card asterisk like CN=* ? Personally I'm completely against any kind of MITM and rather would block https/port 443 altogether as a better policy....but I guess this any discussion about this subject is beyond the scope of this discussion.
I'm not sure, but would be a configuration hack (about:config) or similar possible to allow the old behavior, whereas the one proposed from Nelson would be the default? But I'm sure it's hard to please everybody on such issues. -- Regards Signer: Eddy Nigg, StartCom Ltd. <http://www.startcom.org> Jabber: [EMAIL PROTECTED] <xmpp:[EMAIL PROTECTED]> Blog: Join the Revolution! <http://blog.startcom.org> Phone: +1.213.341.0390 Kyle Hamilton wrote: > Two short, practical examples, which are gleaned from reality (though > I am not at liberty to state of what organizations I speak): > > One, educational institution. Due to compliance issues with student > data being improperly smuggled out of the administration area (in > reaction to an audit that found substantial lack of compliance with > the educational record privacy laws), a comprehensive "there is no way > that anything can leave without our knowing and tracing it" policy was > put in place. USB memory sticks and cards were prohibited, and all > outbound traffic was routed through a proxy. This proxy would behave > normally in HTTP, and any HTTP CONNECT request was MITM'ed for > recording purposes. Employees were notified that all of their machine > and network activity were subject to logging, and were explicitly told > that there was no expectation of privacy on the network. The MITMed > connections were all given the same wildcarded security certificate, > signed by an organizational CA which certificate was loaded into all > browsers. > > (Technically, Nelson's proposal wouldn't cause a complete breakage, as > long as there was sufficient horsepower and sufficient lack of > controls available for the organizational CA to issue certificates at > the request of the proxy server -- it could generate a key or use one > of a pregenerated set of keys, send off the CSR with the name of the > site that the client is sending the CONNECT request for, get an > immediate return of the certificate signed by the organizational CA, > load it, and then return that to the client. However, this goes very > much against security best practices [a security-related operation > performed automatically and without supervision by a CA with > organization-wide trust at the request of an entity which is subject > to attack from both internal and external threats].) > > > Two, hospital. Due to HIPAA compliance issues, they must monitor all > communications originating within their network, and as such they've > put a proxy in place. One of their employees figured out how to to > perform SSH over HTTP CONNECT; since this isn't appreciated by their > MIS department, they broke any protocol negotiation other than SSL and > TLS. Said employee didn't stop, though, and figured out a way to do > an stunnel through which he ssh'es. This tunnel is unmonitored and > completely opaque to the hospital MIS department. (He currently uses > it to gain access to IRC and various talkers. While that employee is > ethical and won't use it for anything which is expressly illegal... > the fact that he can do what he's doing without detection means that > others can do what /they/ want to do without detection. Including > transmit "personally identifiable health information" without proper > consent.) > > > You'll run into the same issue in financial environments (fiduciary > laws), public corporations (Sarbanes-Oxley and GLBA, aka the > "Victoria's Secret" Law), health care providers (HIPAA), and all sorts > of other places that need to ensure that communications are compliant > with the law. MITM is unfortunately often necessary in these > environments. > _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
