24 ms·

Intent to deprecate: Insecure HTTP

180 points by dochtman 12y ago

malkia 12y ago
Do child protection software filters work with HTTPS?
- ikeboy 12y ago
  If they're installed on the computer, then they can easily use a self-signed cert to intercept (like Superfish, but hopefully generating a new one for each device). But they generally just block domains, or use extensions, neither of which care about http/s. A quick search shows that https://www.netnanny.com/products/netnanny/ https://www.netnanny.com/products/netnanny/ says it works against SSL.
  - malkia 12y ago
    My question is more in the line of - wifi provided by school that blocks/filters content. But thanks for the other answers too! (I'm concerned if a kid browses with iPad, some telephone, etc., and the concern is more on whoever provides the service that might be liable in some way).
    - nickspacek 12y ago
      Only domain/IP-level blocking would work for public/free WiFi-style connections. The filtering wouldn't be able to inspect the contents of the pages that are transferred without perform MITM decryption/encryption, and to do that you need a certificate installed on the user's device.
    - ikeboy 12y ago
      They could block whole domains, which https doesn't change. The only time it makes a difference is if you want to block part of a domain and not other parts. I can think of some use cases (block Google unsafe search, but not safesearch), but generally they just block the whole domain and have a separate domain for the "good" part. (See http://www.safesearchkids.com/ http://www.safesearchkids.com/, for example.) And it's not like this isn't the same situation now. Whatever would be possible then would also be possible now, just by using https. This is just making http harder to use.
      - cbhl 12y ago
        Schools do strange things all the time; they'll want to allow YouTube and block Google Drive and Dropbox (because, heaven forbid a student download an arbitrary .exe onto the school's Windows computers and run it, but for some reason opening notepad to create a .bat file locally is perfectly OK).
        ikeboy 12y ago
        If we're talking about school computers, they can put whatever self-signed certs they want on them. Besides, what you described is still domain specific. If you want to block only certain Youtube videos, that's where you'll have a problem.
- zurn 12y ago
  Child protection filters would work much better as browser extensions.
  - sarciszewski 12y ago
    Yep. They can even use something like Google Chrome's malware protection scheme. http://stackoverflow.com/questions/18447874/google-chrome-usage-of-bloom-filter http://stackoverflow.com/questions/18447874/google-chrome-us...
  - nfoz 12y ago
    Why? I'm not familiar with how those typically work, but intuitively from an architecture standpoint, that sounds like something that should sit as a filter between the browser and the outside world. Browser as monolith of functionality seems undesirable.
    - nickspacek 12y ago
      Reason being that with SSL you can't read the contents of the Request/Response (including page content) without MITM, which would require you to install a certificate on the user's device. That may be an option in some situations. With a browser extension (which you would also need to get installed on the device in some manner) you can inspect the pages as they are displayed.
    - untog 12y ago
      Well, because in this HTTPS world, the web browser is the only entity that will be able to view the content being given to the user.
    - AlyssaRowan 12y ago
      Trusted filters (such as ad blockers, parental censorware, network monitoring) must to be inside the trust boundary to be effective. That is the best way to ensure they are not imposed en masse against people's will. In-path filters outside the trust boundary are, I'm afraid, the very first casualty in our efforts to mitigate the threats of nation state adversaries, as they resemble the attacks used there too much to survive. I, for one, will not mourn them.
exelius 12y ago
All I ask is please don't block non-HTTPS sites from browsers. I don't want to have to set up a valid SSL cert for every development environment I work with.
- Navarr 12y ago
  Couldn't you make your own root authority, install it locally, and sign a wildcard cert to cover your dev websites? For example, if they're all *.local that wouldn't be easily abusable.
  - exelius 12y ago
    That's a lot of trouble to go through that I don't today. Everything in production is fronted by a load balancer that terminates SSL, so I never have to worry about SSL certs in the course of a normal day.
    - 15155 12y ago
      It's a bit of trouble because no project has made it really easy yet. All-in-all, this is something that could easily be made into an app and automated.
      - exelius 12y ago
        No, it's a bit of trouble because security takes time to set up. To automate this, you would need a CA that is trusted by your (and the rest of your team's) browser that also creates arbitrary certs upon request. You can see why this is a bad idea. Secure versions of this exist - and the security requirements they introduce are part of the reason enterprise IT is so much of a pain in the ass.
        IgorPartola 12y ago
        Honestly, I have no problem with plain HTTP support being available but only enabled via about:config. If you are a developer, sure go for it. Having said that, the suggestion of running your own CA for your dev environments takes less time to grok and set up than Python's VirtualEnvWrapper.
brlewis 12y ago
It's unfortunate that this is necessary. I like the concept of decentralized cache systems, but in the future CDN will be the only option for low latency.
- Animats 12y ago
  That's what bothers me. HTTPS Everywhere means MITM Everywhere. Terminating HTTPS connections at a CDN means the CDN is the man in the middle. You don't have to attack secure servers that handle important stuff any more; just get a backdoor into Cloudflare. This makes "authorized law enforcement access" easier than ever. On top of that, HTTP2's "it all has to go through one hole" approach means that CDNs become almost mandatory for big sites. The Web is becoming a lot more centralized. It's more secure against random attackers, but much less secure from inside jobs at CDNs, authorized or not. The Great Firewall of China people must love this.
  - M2Ys4U 12y ago
    >That's what bothers me. HTTPS Everywhere means MITM Everywhere. Terminating HTTPS connections at a CDN means the CDN is the man in the middle. CDNs are already Men In The Middle.
  - exelius 12y ago
    CDNs are already mandatory for big sites and have been for a decade or more. There's just no other way to scale and keep a handle on costs. If you don't use a CDN, you'll get murdered by transit costs (Netflix learned this the hard way before they built OpenConnect -- an in-house CDN).
  - jerf 12y ago
    HTTPS has never guaranteed that you were speaking directly to a given entity. In the case of a corporation, what does that really mean, anyhow? Your web request is being handled by the CEO him- or herself? It only means you are speaking to a device or set of devices that the certificate-holding entity has authorized to speak for them. No certificate technology can prevent a company from delegating authority to another entity's devices. It isn't that this isn't necessarily a problem... it is that there is no way in which certificates ever solved it, nor a way in which it can solve it, and there's no choice. Whenever you're talking to X.com, you are almost certainly also talking to a third-party web stack, for instance, which means that trust has been delegated by the certificate holder to some other party's software. There's hardly a website around that doesn't have a whackload (technical term) of third parties already in the connection anyhow. The certificate-holding entity is ultimately responsible for what they do with your trust. But the certificate can do nothing to constrain those actions. It's just a glorified number with some other glorified numbers attached to it. It does seem to me though that HTTP2 should actually make it easier to do without a CDN in the end, though. Initial HTTP2 support will just be "HTTP1, but on HTTP2!" which really provides minimal advantages over HTTP1, but over time as we see web frameworks start to take direct advantage of being able to push down resources preemptively, the advantages of CDNs for all but the largest sites start to fade. (Perhaps not "eliminated", but certainly lessened.) (Incidentally, as people will presumably start releasing HTTP2 benchmarks soon, keep on eye on the details. Embedding HTTP1 inside HTTP2 is not the interesting performance question and will never have big gains... the correct question to investigate is what are the gains to be had from fully using HTTP2 natively. Many SPDY benchmarks had the same problem... of course SPDY isn't faster if it's still essentially speaking HTTP1 to the target website.)
wyldfire 12y ago
I find myself with some cognitive dissonance. This makes perfect sense. But selfishly, I've worked for many corporations that operate an http proxy that they scrutinize and they proxy https which they cannot scrutinize (without detection), so I feel comfortable that they are not. (Yes I periodically review the certificate store for changes). If the vast majority of sites were https, they might decide to do MITM for those https connections and either instruct everyone to ignore the warning or install their own certs on all of the computers. Indeed I think many corporations may already do this. I would probably not use many websites if they made that change.
- jerf 12y ago
  This ship has long since sailed. SSL HTTPS interception for corporate entities is off-the-shelf and readily available.
- jfoutz 12y ago
  Wouldn't the corporation install it's own root certificate in that case? you can MITM without notification. presumably they could tack it on after workstation install. If they're already going through the trouble of monitoring everyone's traffic, a few extra steps don't seem like that big of a hassle. Of course, you're right, some large fraction won't bother with their own root cert, and their users will learn many bad habits.
  - wyldfire 12y ago
    > Wouldn't the corporation install it's own root certificate in that case? Yeah, but I can audit the certificate store (and I have). On some systems, I am granted local administrator privilege. I wouldn't take out any certs that they install, but if I found that they installed and/or used one, I'd probably stop using most public websites (at least the ones that I have a username/password with).
- andrewstuart2 12y ago
  I don't think there's anything inherently bad about trusted MITM. If the trust exists, then you can have a local caching proxy that can drastically reduce the load on servers, WAN links, etc, and is a major part of Roy Fielding's original description of the REST architecture. [1] IMO, I think the majority of use cases that people care about with HTTPS are about integrity (i.e. authentication) rather than confidentiality. We don't need full-on encrypted requests for those use cases, we just need secure MACs[2] (significant performance difference) as part of the standard so that endpoints can verify it hasn't been tampered with, even if it's been cached somewhere along the way. [1]https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_2_2 https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arc... [2]http://en.wikipedia.org/wiki/Message_authentication_code http://en.wikipedia.org/wiki/Message_authentication_code
josho 12y ago
What is the point? If you need a secure connection then use https, if there is no value securing the connection then use http. Why deprecate a working technology that continues to have many valid use cases? As an analogy this strikes me as deprecating an array for a linked list because a list has certain features that array's don't. Ie. there is a time and place for both.
- mabbo 12y ago
  Can you list some of the use cases where you can do something using HTTP that you can't using HTTPS? I had always assumed one was a superset of the other, feature-wise. As long as HTTPS offers all features of HTTP, then the reason to deprecate HTTP is to prevent accidental use of it, and websites which don't know/care from leaving their users vulnerable.
  - chc 12y ago
    Beware of the Turing tar-pit in which everything is possible but nothing of interest is easy. In theory, HTTP is a subset of HTTPS. But that subset is much simpler for common tasks. HTTPS requires you to either subject yourself to the complexities of the CA system or be accused constantly of attacking yourself and everyone else who visits.
    - blowski 12y ago
      So why not require HTTPS, and let a thousand "make HTTPS simple" startups bloom? Seems like we're saying "we should just accept insecurity because we can't think of an alternative".
      - chc 12y ago
        > So why not require HTTPS, and let a thousand "make HTTPS simple" startups bloom? Much the same reason we don't all cut our hands off and let a thousand prosthetics startups bloom, I think. > Seems like we're saying "we should just accept insecurity because we can't think of an alternative". It seems more like we're saying "We should unnecessarily break the free Web and just cross our fingers that somebody figures out how to fix it sooner or later."
nadams 12y ago
I know Google wants to do something similar with Chrome. I have so many comments - but the first being don't they realize that they will have to make this option which will be disabled by most enterprises?
bifurcation 12y ago
Hey, this is Richard, the author of the post. All the feedback here is great, but if you've got thoughts on whether we should pursue this strategy or not, please comment on the mozilla.dev.platform list. https://lists.mozilla.org/listinfo/dev-platform https://lists.mozilla.org/listinfo/dev-platform https://groups.google.com/forum/#!forum/mozilla.dev.platform https://groups.google.com/forum/#!forum/mozilla.dev.platform
- deleted 12y ago
  [deleted]
- yellowapple 12y ago
  As I mentioned in the thread in question: "Basically, the current CA system is - again, to put this as gently and politely as possible - fucking broken. Anything that forces the world to rely on it exclusively is not a solution, but is instead just going to make the problem worse." Please keep that fact - that the CA system is, as I put it with all the gentleness and politeness it deserves, "fucking broken" beyond any repair - in mind. (And no, "the CA system is fucking broken" is not an opinion; it is a verifiable fact, as much as the concept of gravity is a verifiable fact)
  - brazzledazzle 12y ago
    If it's not a bother can you elaborate on the way(s) it's irreparably broken?
    - bandrami 12y ago
      Seriously? Just on my Debian box there are 173 entities (along with all their employees, disgruntled employees, hackers, and probably governments) who can sign a certificate for google.com that my computer will accept. I can think of five cases in as many years off the top of my head of a fake google.com (or related) certificate being found in the wild by Google because of various levels of CA incompetence and/or fraud. Worse yet, this bungled attempt at authenticity has been awkwardly nailed to the much simpler (and in most cases much more important) question of cryptographic security, with the result that going through the absurd charade of convincing a CA of my identity is required simply to offer a client the assurance that I, whoever I may be and however much the client does or doesn't trust me, actually sent the message the client received and that nobody in transit could read it.
jackreichert 12y ago
In order for this to really take off a campaign with the popular basic plug and play hosting providers to install free/cheap SSL would be needed.
dragonwriter 12y ago
Generally, I think this is a bad approach. I think that configurable blocking of HTTP with user-controlled (or, for managed environments, policy-controlled) opt-in to allow HTTP for safe domains makes some sense. But not deploying new features for HTTP and limiting existing features on HTTP does not; true, one could set up a root CA and deploy certificates and manage TLS for internal, including local-box, testing, etc., but it doesn't make sense for browser to require it. Configurable blocking of HTTP provides all the benefits of HTTP deprecation without the adverse side effects for the situations where HTTPS is an unnecessary headache, so it should be preferred.
mark-r 12y ago
Doesn't HTTPS require a dedicated IP address? With the exhaustion of the IPv4 address space, the timing couldn't be worse.
- Dylan16807 12y ago
  No, they fixed that. The hostname is sent before the cert is chosen.
  - rstupek 12y ago
    No it isn't fixed for all devices. Windows XP is one example and even though it is no longer supported by Microsoft, at least 17% of devices on the internet are still using it.
    - Dylan16807 12y ago
      That's not a problem with XP, that's a problem with people that use obsolete versions of IE. Note that the subject here is talking about what to do in future browser versions, so IE8 never comes into the picture.
  - bandrami 12y ago
    Meaning the hostname is also sent in cleartext (which may be problematic for some use cases). This is the wrong level to be talking about this anyways. IPSec is the "right" thing to do, but that ship sailed I guess.
    - Dylan16807 12y ago
      Problematic in what cases? You could always get hostname from the IP before.
      - bandrami 12y ago
        You can get a PTR from an IP address, but that's not the same as "the hostname the client requested". If virtuous_activities.com and shameful_fetishes.com both resolve to the same IP address (assuming some application protocol like HTTP that can distinguish by hostname) I could certainly imagine a situation where a client would want to keep the particular hostname requested secret. (Obviously the attacker in this case would probably also be able to sniff the requests from the resolver, but still; I'm not making this complaint up or anything, a lot of people have mentioned it before.)
aidenn0 12y ago
The recent disabling of TLS1.0 on so many sites means I'm finally going to have to upgrade my cell-phone, as there aren't any TLS1.1+ supported browsers for PalmOS.
- MrRadar 12y ago
  What sites are disabling TLS 1.0? According to the SSL Pulse report[1] it's the most-supported version of SSL/TLS by far (99.7% support). TLS 1.1 and 1.2 are disabled by default in older versions of Internet Explorer so not supporting 1.0 would lose those viewers which is enough reason to keep it enabled for almost all HTTPS sites. [1] https://www.trustworthyinternet.org/ssl-pulse/ https://www.trustworthyinternet.org/ssl-pulse/
  - deleted 12y ago
    [deleted]
  - aidenn0 12y ago
    Sorry, my mistake, it's SSL 3; I can't even load the Qualys SSL client test.
IgorPartola 12y ago
I am wondering if this will go anywhere. It seems to me that if anyone would be willing to do this it would actually be the Chrome team, not Mozilla. Mozilla currently lacks the market share to pull this off, and lately their moves have been more targeted in a different direction. Having said that, I am really happy others are thinking along the same lines as I: HTTP should be relegated to a legacy protocol and the warnings need to very similar to what you get when accessing a site secured by a self-signed cert.
0x0 12y ago
The biggest downside I see is that it would no longer be possible to host a simple website, without also having to publicly expose the vastly increased attack surface that the OpenSSL code base brings to the table.
jwr 12y ago
How about we solve the "certificate" situation first? I've just paid lots of money for "certificates". I quote the word, because they don't actually certify or even signify anything. The whole procedure for "domain-verification" is a joke, and many outfits are incompetently run (their "verification" e-mails bounced from my servers because they ended up in RBL, which nobody seemed fit to correct). I see this as a scam, or extortion — pay up, or you won't be "certified". And pay up significant amounts of money, if you want a wildcard cert. If we care about encryption just for the sake of encryption, let's change our browsers to allow self-signed certificates. Label them as such, but don't label them as "unsecure", because the padlock icon really isn't any more secure than a self-signed cert.
- glesica 12y ago
  This is especially bad on Firefox where the dialog to allow a self-signed cert isn't even very intuitive. At least on Chrome (last I checked, anyway) there is a clear "correct" thing to do if you want to allow the cert.
- byuu 12y ago
  But what kind of technology would think self-signed certificates could ever be better (let alone not infinitely worse) than no encryption at all? That sounds like hell. We should call this new, purely hypothetical protocol, SSHell, or SSH for short. Not that such a thing would ever be used by anyone, of course. (Yes, I know that technically SSH uses key pairs; but they show you the key, you choose to trust it. Same real chance of a MITM as with a self-signed SSL certificate. But at least you (and others) can now detect when there's a change in who's sending your data, and choose who to trust yourself instead of relying on Mozilla to pick who to trust, like they did CNNIC.)
  - rando3826 12y ago
    Lol, took me a minute to get the sarcasm.
  - xorcist 12y ago
    The trust-on-first-use model makes it hard or impossible to regenerate certificates. If you don't have that problem with SSH it is because you connect to your own servers only. There have been several attempts for a distributing certificate checks on the wider Internet, but they all come with their own set of problems.
fiatjaf 12y ago
What the hell. Someone please stop this madness.
fiatjaf 12y ago
First .google domains, now this? We should stop using this stupid thing named DNS. https://gnunet.org/gns https://gnunet.org/gns
baby 12y ago
In my opinion: * A big warning sign when the site is not using TLS, but not a pop-up * No warning when the site is using TLS That would be a correct way to force websites to use TLS.
api 12y ago
I agree with some of the skeptical comments here, and wanted to add one more use case they are not thinking about: http://localhost:NNN/ http://localhost:NNN/ There are many cases where you might want a service on localhost to be reachable via HTTP. Technically this should be exempt from https rules entirely, since who would the man in the middle be? If someone can MITM 127.0.0.1, they own your box already. It is impossible to get https certificates for localhost/127.0.0.1, making SSL with an approved cert impossible for local services.
pilif 12y ago
If this is a very long-term plan, I'm all up for it. In the short term, we're just not quite where we need to be in order to enable SSL even on less-important sites or sites that don't require any credentials. From a hardware perspective, I'd say that by now the problem is actually solved. Hardware is powerful enough to handle SSL connections. What's currently tricky is that too big a chunk of clients still doesn't support SNI which really doesn't go well with the increasing scarceness of IP addresses. Needing one IP address per unique domain name, aside of the administrative overhead (multi-homing still is somewhat inconvenient) will just not be feasible as the costs for IP addresses is starting to skyrocket. This will be fixed by either IPv6 growth (you wish) or the death of non-SNI systems, but it'll be years if not decades before we can ignore XP and Android 2.3, especially as there's no good fallback path for these clients as the SSL negotiation (and subsequent hostname validation failure) happens way before the host could react.
- kijin 12y ago
  > Needing one IP address per unique domain name I'm tired of this bullshit. This has never been true, not even 10 years ago. You only need one IP:port combination per unique domain name. You can host tens of thousands of HTTPS websites on a single IP even if none of your users support SNI, and you don't have to pay for a SAN certificate, either. You can serve HTTPS on port 31276 as long as you redirect properly from plain HTTP. You could even redirect conditionally, i.e. modern browsers and search engines are redirected to port 443 while the remainder are told to try port 31276. Is this ugly? Yes. Do people care? No. A client of mine who uses shared hosting is perfectly happy with HTTPS on port 44527. Most people don't even look at the URL. Who knows, they might even think that the secret number makes their website more secure. (Of course it doesn't, but their misconception doesn't make their website any less secure, so I don't care.) Older browsers not supporting secure ciphers/protocols is a bigger problem, but you can also get around this to some extent by offering better ciphers/protocols on port 443 and lesser ciphers/protocols on an alternate port.
  - pilif 12y ago
    Yeah. Sure. Non-standard ports will work really well in combination with enterprise firewalls. I would furthermore wager a guess that the intersection between XP users and users behind firewalls is quite big, actually.
maxk42 12y ago
Nobody has brought this up yet: If we deprecate HTTP, then certificates can be used as tools of censorship by governments. We require an alternative to the current HTTPS scheme first.
- userbinator 12y ago
  ...and the governments will then be virtually the only ones who can still inspect traffic, since they can still get CAs to issue certificates for them. Moving everything to HTTPS dependent upon CAs only makes the whole Internet more centralised, which is horrible for privacy and anonymity. They will all say it's "for your security", and arguably having this centralised root of trust does lower risk of attacks from random groups, but at the same time it's allowing them more power. To CAs and governments, a lot of things around encryption seem to be oriented in the direction of "if we don't have control over it, we disapprove." Self-signed certs are only one example of this; see all the other issues surrounding mobile device encryption. It's only good encryption to them if they are the ones in control of it. Quite frankly, to me it seems random hacker groups have a lower chance of cooperating and tracking you in the same way that governments can. I believe the relevant quote in this situation is again the classic "those who give up freedom for security deserve neither."
gbl08ma 12y ago
I'm not saying it's a bad idea, but the thought that once HTTP is deprecated I'll need to go through extra effort to manage the myriad of devices in my LAN is bothering me. The configuration interfaces of these devices (routers, printers, IP cameras, etc.) mostly don't support HTTP. Most never had updates available and certainly never will. We're not just talking about 5+ year old devices (which despite their age still function as designed): none of the most recent routers I bought support it, except if flashed with some powerful and well maintained alternative firmware. I'm already annoyed enough by firmware update tools that only work with a specific old version of Internet Explorer... I rather not throw dozens of equipment away just because browsers started to insistently refuse HTTP connections. Let's not talk about the fact that I often spin up simple HTTP servers on my computer just to be able to transfer files to other machines on the same network, and I rather not have to worry about creating certificates (to then find out that the machines in question are "obsolete" too and don't support HTTPS?). Can we just consider HTTP to be like telnet? Old, super insecure, definitely not meant to be used by everyone daily and definitely not over the Internet, perhaps not even available/installed by default, yet super compatible and simple to implement both for the client and the server. I really hope that should mandatory HTTPS become a thing (and I'm not saying it shouldn't), an exception is added for local area connections.
- Sir_Cmpwn 12y ago
  Share those thoughts on the mailing list.
- higherpurpose 12y ago
  This just makes me think that we need is not an "improved HTTPS", but to rip out TCP/IP and encrypt everything at that level. Now we only need to convince either Google or Microsoft to implement something like that in their OS and encourage/mandate the use of it. Only these 2 matter because they are the owners of the biggest platforms. Yes Apple has a pretty big platform, too, but it's kind of irrelevant since it's a closed Apple-only ecosystem anyway so if it adopts something it doesn't mean the others will too. On the other hand, if either Android or Windows adopts something as major, I think the other one would, too. What I'm thinking is something like MinimaLT or perhaps Trevor Perrin's "Noise" if it ever becomes real. http://cr.yp.to/tcpip/minimalt-20131031.pdf http://cr.yp.to/tcpip/minimalt-20131031.pdf
zaroth 12y ago
What about devices I access via IP address which have no DNS. Like my home router, or my printer, or my iPhone when I'm connecting to an admin web interface, or my NAS...? Obviously I'm not going to setup a home domain, DNS, and SSL certs installed on all these devices just so they can use the latest HTTP/2.x features in their admin panels or user interfaces?
gurushackers 12y ago
We are the real deal in all degree of hacking. Superb Hackers have proofs with confirmation from our numerous clients around the world. Our job is done without any trace. We render the following services at an affordable price. +University grades changing +Facebook hack +email interception hack +email accounts hack +Grade Changes hack +Website crashed hack +Word Press Blogs hack +Retrieval of lost file/documents +Erase criminal records hack +Databases hack +Sales of Dumps cards of all kinds +Untraceable Ip +Bank accounts hack +Individual computers hack +Websites hack +Control devices remotely hack +Burner Numbers hack +Verified Paypal Accounts hack +Any social media account hack +Android & iPhone Hack +server crashed hack +Text message interception hack +Twitters hack +Skype hack +Credit cards hacker +We can drop money into bank accounts. We can also teach you how to do the following with our e-book and online tutorials * Hack and use Credit Card to shop online * Monitor any phone and email address * Tap into anybody's call and monitor their conversation CONTACT: gurushackers@yahoo.com

180 points by dochtman 12y ago

malkia 12y ago

Do child protection software filters work with HTTPS?

ikeboy 12y ago
If they're installed on the computer, then they can easily use a self-signed cert to intercept (like Superfish, but hopefully generating a new one for each device). But they generally just block domains, or use extensions, neither of which care about http/s. A quick search shows that https://www.netnanny.com/products/netnanny/ https://www.netnanny.com/products/netnanny/ says it works against SSL.
- malkia 12y ago
  My question is more in the line of - wifi provided by school that blocks/filters content. But thanks for the other answers too! (I'm concerned if a kid browses with iPad, some telephone, etc., and the concern is more on whoever provides the service that might be liable in some way).
  - nickspacek 12y ago
    Only domain/IP-level blocking would work for public/free WiFi-style connections. The filtering wouldn't be able to inspect the contents of the pages that are transferred without perform MITM decryption/encryption, and to do that you need a certificate installed on the user's device.
  - ikeboy 12y ago
    They could block whole domains, which https doesn't change. The only time it makes a difference is if you want to block part of a domain and not other parts. I can think of some use cases (block Google unsafe search, but not safesearch), but generally they just block the whole domain and have a separate domain for the "good" part. (See http://www.safesearchkids.com/ http://www.safesearchkids.com/, for example.) And it's not like this isn't the same situation now. Whatever would be possible then would also be possible now, just by using https. This is just making http harder to use.
    - cbhl 12y ago
      Schools do strange things all the time; they'll want to allow YouTube and block Google Drive and Dropbox (because, heaven forbid a student download an arbitrary .exe onto the school's Windows computers and run it, but for some reason opening notepad to create a .bat file locally is perfectly OK).
      - ikeboy 12y ago
        If we're talking about school computers, they can put whatever self-signed certs they want on them. Besides, what you described is still domain specific. If you want to block only certain Youtube videos, that's where you'll have a problem.
zurn 12y ago
Child protection filters would work much better as browser extensions.
- sarciszewski 12y ago
  Yep. They can even use something like Google Chrome's malware protection scheme. http://stackoverflow.com/questions/18447874/google-chrome-usage-of-bloom-filter http://stackoverflow.com/questions/18447874/google-chrome-us...
- nfoz 12y ago
  Why? I'm not familiar with how those typically work, but intuitively from an architecture standpoint, that sounds like something that should sit as a filter between the browser and the outside world. Browser as monolith of functionality seems undesirable.
  - nickspacek 12y ago
    Reason being that with SSL you can't read the contents of the Request/Response (including page content) without MITM, which would require you to install a certificate on the user's device. That may be an option in some situations. With a browser extension (which you would also need to get installed on the device in some manner) you can inspect the pages as they are displayed.
  - untog 12y ago
    Well, because in this HTTPS world, the web browser is the only entity that will be able to view the content being given to the user.
  - AlyssaRowan 12y ago
    Trusted filters (such as ad blockers, parental censorware, network monitoring) must to be inside the trust boundary to be effective. That is the best way to ensure they are not imposed en masse against people's will. In-path filters outside the trust boundary are, I'm afraid, the very first casualty in our efforts to mitigate the threats of nation state adversaries, as they resemble the attacks used there too much to survive. I, for one, will not mourn them.

exelius 12y ago

All I ask is please don't block non-HTTPS sites from browsers. I don't want to have to set up a valid SSL cert for every development environment I work with.

Navarr 12y ago
Couldn't you make your own root authority, install it locally, and sign a wildcard cert to cover your dev websites? For example, if they're all *.local that wouldn't be easily abusable.
- exelius 12y ago
  That's a lot of trouble to go through that I don't today. Everything in production is fronted by a load balancer that terminates SSL, so I never have to worry about SSL certs in the course of a normal day.
  - 15155 12y ago
    It's a bit of trouble because no project has made it really easy yet. All-in-all, this is something that could easily be made into an app and automated.
    - exelius 12y ago
      No, it's a bit of trouble because security takes time to set up. To automate this, you would need a CA that is trusted by your (and the rest of your team's) browser that also creates arbitrary certs upon request. You can see why this is a bad idea. Secure versions of this exist - and the security requirements they introduce are part of the reason enterprise IT is so much of a pain in the ass.
      - IgorPartola 12y ago
        Honestly, I have no problem with plain HTTP support being available but only enabled via about:config. If you are a developer, sure go for it. Having said that, the suggestion of running your own CA for your dev environments takes less time to grok and set up than Python's VirtualEnvWrapper.

brlewis 12y ago

It's unfortunate that this is necessary. I like the concept of decentralized cache systems, but in the future CDN will be the only option for low latency.

Animats 12y ago
That's what bothers me. HTTPS Everywhere means MITM Everywhere. Terminating HTTPS connections at a CDN means the CDN is the man in the middle. You don't have to attack secure servers that handle important stuff any more; just get a backdoor into Cloudflare. This makes "authorized law enforcement access" easier than ever. On top of that, HTTP2's "it all has to go through one hole" approach means that CDNs become almost mandatory for big sites. The Web is becoming a lot more centralized. It's more secure against random attackers, but much less secure from inside jobs at CDNs, authorized or not. The Great Firewall of China people must love this.
- M2Ys4U 12y ago
  >That's what bothers me. HTTPS Everywhere means MITM Everywhere. Terminating HTTPS connections at a CDN means the CDN is the man in the middle. CDNs are already Men In The Middle.
- exelius 12y ago
  CDNs are already mandatory for big sites and have been for a decade or more. There's just no other way to scale and keep a handle on costs. If you don't use a CDN, you'll get murdered by transit costs (Netflix learned this the hard way before they built OpenConnect -- an in-house CDN).
- jerf 12y ago
  HTTPS has never guaranteed that you were speaking directly to a given entity. In the case of a corporation, what does that really mean, anyhow? Your web request is being handled by the CEO him- or herself? It only means you are speaking to a device or set of devices that the certificate-holding entity has authorized to speak for them. No certificate technology can prevent a company from delegating authority to another entity's devices. It isn't that this isn't necessarily a problem... it is that there is no way in which certificates ever solved it, nor a way in which it can solve it, and there's no choice. Whenever you're talking to X.com, you are almost certainly also talking to a third-party web stack, for instance, which means that trust has been delegated by the certificate holder to some other party's software. There's hardly a website around that doesn't have a whackload (technical term) of third parties already in the connection anyhow. The certificate-holding entity is ultimately responsible for what they do with your trust. But the certificate can do nothing to constrain those actions. It's just a glorified number with some other glorified numbers attached to it. It does seem to me though that HTTP2 should actually make it easier to do without a CDN in the end, though. Initial HTTP2 support will just be "HTTP1, but on HTTP2!" which really provides minimal advantages over HTTP1, but over time as we see web frameworks start to take direct advantage of being able to push down resources preemptively, the advantages of CDNs for all but the largest sites start to fade. (Perhaps not "eliminated", but certainly lessened.) (Incidentally, as people will presumably start releasing HTTP2 benchmarks soon, keep on eye on the details. Embedding HTTP1 inside HTTP2 is not the interesting performance question and will never have big gains... the correct question to investigate is what are the gains to be had from fully using HTTP2 natively. Many SPDY benchmarks had the same problem... of course SPDY isn't faster if it's still essentially speaking HTTP1 to the target website.)

wyldfire 12y ago

I find myself with some cognitive dissonance. This makes perfect sense. But selfishly, I've worked for many corporations that operate an http proxy that they scrutinize and they proxy https which they cannot scrutinize (without detection), so I feel comfortable that they are not. (Yes I periodically review the certificate store for changes). If the vast majority of sites were https, they might decide to do MITM for those https connections and either instruct everyone to ignore the warning or install their own certs on all of the computers. Indeed I think many corporations may already do this. I would probably not use many websites if they made that change.

jerf 12y ago
This ship has long since sailed. SSL HTTPS interception for corporate entities is off-the-shelf and readily available.
jfoutz 12y ago
Wouldn't the corporation install it's own root certificate in that case? you can MITM without notification. presumably they could tack it on after workstation install. If they're already going through the trouble of monitoring everyone's traffic, a few extra steps don't seem like that big of a hassle. Of course, you're right, some large fraction won't bother with their own root cert, and their users will learn many bad habits.
- wyldfire 12y ago
  > Wouldn't the corporation install it's own root certificate in that case? Yeah, but I can audit the certificate store (and I have). On some systems, I am granted local administrator privilege. I wouldn't take out any certs that they install, but if I found that they installed and/or used one, I'd probably stop using most public websites (at least the ones that I have a username/password with).
andrewstuart2 12y ago
I don't think there's anything inherently bad about trusted MITM. If the trust exists, then you can have a local caching proxy that can drastically reduce the load on servers, WAN links, etc, and is a major part of Roy Fielding's original description of the REST architecture. [1] IMO, I think the majority of use cases that people care about with HTTPS are about integrity (i.e. authentication) rather than confidentiality. We don't need full-on encrypted requests for those use cases, we just need secure MACs[2] (significant performance difference) as part of the standard so that endpoints can verify it hasn't been tampered with, even if it's been cached somewhere along the way. [1]https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_2_2 https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arc... [2]http://en.wikipedia.org/wiki/Message_authentication_code http://en.wikipedia.org/wiki/Message_authentication_code

josho 12y ago

What is the point? If you need a secure connection then use https, if there is no value securing the connection then use http. Why deprecate a working technology that continues to have many valid use cases? As an analogy this strikes me as deprecating an array for a linked list because a list has certain features that array's don't. Ie. there is a time and place for both.

mabbo 12y ago
Can you list some of the use cases where you can do something using HTTP that you can't using HTTPS? I had always assumed one was a superset of the other, feature-wise. As long as HTTPS offers all features of HTTP, then the reason to deprecate HTTP is to prevent accidental use of it, and websites which don't know/care from leaving their users vulnerable.
- chc 12y ago
  Beware of the Turing tar-pit in which everything is possible but nothing of interest is easy. In theory, HTTP is a subset of HTTPS. But that subset is much simpler for common tasks. HTTPS requires you to either subject yourself to the complexities of the CA system or be accused constantly of attacking yourself and everyone else who visits.
  - blowski 12y ago
    So why not require HTTPS, and let a thousand "make HTTPS simple" startups bloom? Seems like we're saying "we should just accept insecurity because we can't think of an alternative".
    - chc 12y ago
      > So why not require HTTPS, and let a thousand "make HTTPS simple" startups bloom? Much the same reason we don't all cut our hands off and let a thousand prosthetics startups bloom, I think. > Seems like we're saying "we should just accept insecurity because we can't think of an alternative". It seems more like we're saying "We should unnecessarily break the free Web and just cross our fingers that somebody figures out how to fix it sooner or later."

nadams 12y ago

I know Google wants to do something similar with Chrome. I have so many comments - but the first being don't they realize that they will have to make this option which will be disabled by most enterprises?

bifurcation 12y ago

Hey, this is Richard, the author of the post. All the feedback here is great, but if you've got thoughts on whether we should pursue this strategy or not, please comment on the mozilla.dev.platform list. https://lists.mozilla.org/listinfo/dev-platform https://lists.mozilla.org/listinfo/dev-platform https://groups.google.com/forum/#!forum/mozilla.dev.platform https://groups.google.com/forum/#!forum/mozilla.dev.platform

deleted 12y ago
[deleted]
yellowapple 12y ago
As I mentioned in the thread in question: "Basically, the current CA system is - again, to put this as gently and politely as possible - fucking broken. Anything that forces the world to rely on it exclusively is not a solution, but is instead just going to make the problem worse." Please keep that fact - that the CA system is, as I put it with all the gentleness and politeness it deserves, "fucking broken" beyond any repair - in mind. (And no, "the CA system is fucking broken" is not an opinion; it is a verifiable fact, as much as the concept of gravity is a verifiable fact)
- brazzledazzle 12y ago
  If it's not a bother can you elaborate on the way(s) it's irreparably broken?
  - bandrami 12y ago
    Seriously? Just on my Debian box there are 173 entities (along with all their employees, disgruntled employees, hackers, and probably governments) who can sign a certificate for google.com that my computer will accept. I can think of five cases in as many years off the top of my head of a fake google.com (or related) certificate being found in the wild by Google because of various levels of CA incompetence and/or fraud. Worse yet, this bungled attempt at authenticity has been awkwardly nailed to the much simpler (and in most cases much more important) question of cryptographic security, with the result that going through the absurd charade of convincing a CA of my identity is required simply to offer a client the assurance that I, whoever I may be and however much the client does or doesn't trust me, actually sent the message the client received and that nobody in transit could read it.

jackreichert 12y ago

In order for this to really take off a campaign with the popular basic plug and play hosting providers to install free/cheap SSL would be needed.

dragonwriter 12y ago

Generally, I think this is a bad approach. I think that configurable blocking of HTTP with user-controlled (or, for managed environments, policy-controlled) opt-in to allow HTTP for safe domains makes some sense. But not deploying new features for HTTP and limiting existing features on HTTP does not; true, one could set up a root CA and deploy certificates and manage TLS for internal, including local-box, testing, etc., but it doesn't make sense for browser to require it. Configurable blocking of HTTP provides all the benefits of HTTP deprecation without the adverse side effects for the situations where HTTPS is an unnecessary headache, so it should be preferred.

mark-r 12y ago

Doesn't HTTPS require a dedicated IP address? With the exhaustion of the IPv4 address space, the timing couldn't be worse.

Dylan16807 12y ago
No, they fixed that. The hostname is sent before the cert is chosen.
- rstupek 12y ago
  No it isn't fixed for all devices. Windows XP is one example and even though it is no longer supported by Microsoft, at least 17% of devices on the internet are still using it.
  - Dylan16807 12y ago
    That's not a problem with XP, that's a problem with people that use obsolete versions of IE. Note that the subject here is talking about what to do in future browser versions, so IE8 never comes into the picture.
- bandrami 12y ago
  Meaning the hostname is also sent in cleartext (which may be problematic for some use cases). This is the wrong level to be talking about this anyways. IPSec is the "right" thing to do, but that ship sailed I guess.
  - Dylan16807 12y ago
    Problematic in what cases? You could always get hostname from the IP before.
    - bandrami 12y ago
      You can get a PTR from an IP address, but that's not the same as "the hostname the client requested". If virtuous_activities.com and shameful_fetishes.com both resolve to the same IP address (assuming some application protocol like HTTP that can distinguish by hostname) I could certainly imagine a situation where a client would want to keep the particular hostname requested secret. (Obviously the attacker in this case would probably also be able to sniff the requests from the resolver, but still; I'm not making this complaint up or anything, a lot of people have mentioned it before.)

aidenn0 12y ago

The recent disabling of TLS1.0 on so many sites means I'm finally going to have to upgrade my cell-phone, as there aren't any TLS1.1+ supported browsers for PalmOS.

MrRadar 12y ago
What sites are disabling TLS 1.0? According to the SSL Pulse report[1] it's the most-supported version of SSL/TLS by far (99.7% support). TLS 1.1 and 1.2 are disabled by default in older versions of Internet Explorer so not supporting 1.0 would lose those viewers which is enough reason to keep it enabled for almost all HTTPS sites. [1] https://www.trustworthyinternet.org/ssl-pulse/ https://www.trustworthyinternet.org/ssl-pulse/
- deleted 12y ago
  [deleted]
- aidenn0 12y ago
  Sorry, my mistake, it's SSL 3; I can't even load the Qualys SSL client test.

IgorPartola 12y ago

I am wondering if this will go anywhere. It seems to me that if anyone would be willing to do this it would actually be the Chrome team, not Mozilla. Mozilla currently lacks the market share to pull this off, and lately their moves have been more targeted in a different direction. Having said that, I am really happy others are thinking along the same lines as I: HTTP should be relegated to a legacy protocol and the warnings need to very similar to what you get when accessing a site secured by a self-signed cert.

0x0 12y ago

The biggest downside I see is that it would no longer be possible to host a simple website, without also having to publicly expose the vastly increased attack surface that the OpenSSL code base brings to the table.

jwr 12y ago

How about we solve the "certificate" situation first? I've just paid lots of money for "certificates". I quote the word, because they don't actually certify or even signify anything. The whole procedure for "domain-verification" is a joke, and many outfits are incompetently run (their "verification" e-mails bounced from my servers because they ended up in RBL, which nobody seemed fit to correct). I see this as a scam, or extortion — pay up, or you won't be "certified". And pay up significant amounts of money, if you want a wildcard cert. If we care about encryption just for the sake of encryption, let's change our browsers to allow self-signed certificates. Label them as such, but don't label them as "unsecure", because the padlock icon really isn't any more secure than a self-signed cert.

glesica 12y ago
This is especially bad on Firefox where the dialog to allow a self-signed cert isn't even very intuitive. At least on Chrome (last I checked, anyway) there is a clear "correct" thing to do if you want to allow the cert.
byuu 12y ago
But what kind of technology would think self-signed certificates could ever be better (let alone not infinitely worse) than no encryption at all? That sounds like hell. We should call this new, purely hypothetical protocol, SSHell, or SSH for short. Not that such a thing would ever be used by anyone, of course. (Yes, I know that technically SSH uses key pairs; but they show you the key, you choose to trust it. Same real chance of a MITM as with a self-signed SSL certificate. But at least you (and others) can now detect when there's a change in who's sending your data, and choose who to trust yourself instead of relying on Mozilla to pick who to trust, like they did CNNIC.)
- rando3826 12y ago
  Lol, took me a minute to get the sarcasm.
- xorcist 12y ago
  The trust-on-first-use model makes it hard or impossible to regenerate certificates. If you don't have that problem with SSH it is because you connect to your own servers only. There have been several attempts for a distributing certificate checks on the wider Internet, but they all come with their own set of problems.

fiatjaf 12y ago

What the hell. Someone please stop this madness.

fiatjaf 12y ago

First .google domains, now this? We should stop using this stupid thing named DNS. https://gnunet.org/gns https://gnunet.org/gns

baby 12y ago

In my opinion: * A big warning sign when the site is not using TLS, but not a pop-up * No warning when the site is using TLS That would be a correct way to force websites to use TLS.

api 12y ago

I agree with some of the skeptical comments here, and wanted to add one more use case they are not thinking about: http://localhost:NNN/ http://localhost:NNN/ There are many cases where you might want a service on localhost to be reachable via HTTP. Technically this should be exempt from https rules entirely, since who would the man in the middle be? If someone can MITM 127.0.0.1, they own your box already. It is impossible to get https certificates for localhost/127.0.0.1, making SSL with an approved cert impossible for local services.

pilif 12y ago

If this is a very long-term plan, I'm all up for it. In the short term, we're just not quite where we need to be in order to enable SSL even on less-important sites or sites that don't require any credentials. From a hardware perspective, I'd say that by now the problem is actually solved. Hardware is powerful enough to handle SSL connections. What's currently tricky is that too big a chunk of clients still doesn't support SNI which really doesn't go well with the increasing scarceness of IP addresses. Needing one IP address per unique domain name, aside of the administrative overhead (multi-homing still is somewhat inconvenient) will just not be feasible as the costs for IP addresses is starting to skyrocket. This will be fixed by either IPv6 growth (you wish) or the death of non-SNI systems, but it'll be years if not decades before we can ignore XP and Android 2.3, especially as there's no good fallback path for these clients as the SSL negotiation (and subsequent hostname validation failure) happens way before the host could react.

kijin 12y ago
> Needing one IP address per unique domain name I'm tired of this bullshit. This has never been true, not even 10 years ago. You only need one IP:port combination per unique domain name. You can host tens of thousands of HTTPS websites on a single IP even if none of your users support SNI, and you don't have to pay for a SAN certificate, either. You can serve HTTPS on port 31276 as long as you redirect properly from plain HTTP. You could even redirect conditionally, i.e. modern browsers and search engines are redirected to port 443 while the remainder are told to try port 31276. Is this ugly? Yes. Do people care? No. A client of mine who uses shared hosting is perfectly happy with HTTPS on port 44527. Most people don't even look at the URL. Who knows, they might even think that the secret number makes their website more secure. (Of course it doesn't, but their misconception doesn't make their website any less secure, so I don't care.) Older browsers not supporting secure ciphers/protocols is a bigger problem, but you can also get around this to some extent by offering better ciphers/protocols on port 443 and lesser ciphers/protocols on an alternate port.
- pilif 12y ago
  Yeah. Sure. Non-standard ports will work really well in combination with enterprise firewalls. I would furthermore wager a guess that the intersection between XP users and users behind firewalls is quite big, actually.

maxk42 12y ago

Nobody has brought this up yet: If we deprecate HTTP, then certificates can be used as tools of censorship by governments. We require an alternative to the current HTTPS scheme first.

userbinator 12y ago
...and the governments will then be virtually the only ones who can still inspect traffic, since they can still get CAs to issue certificates for them. Moving everything to HTTPS dependent upon CAs only makes the whole Internet more centralised, which is horrible for privacy and anonymity. They will all say it's "for your security", and arguably having this centralised root of trust does lower risk of attacks from random groups, but at the same time it's allowing them more power. To CAs and governments, a lot of things around encryption seem to be oriented in the direction of "if we don't have control over it, we disapprove." Self-signed certs are only one example of this; see all the other issues surrounding mobile device encryption. It's only good encryption to them if they are the ones in control of it. Quite frankly, to me it seems random hacker groups have a lower chance of cooperating and tracking you in the same way that governments can. I believe the relevant quote in this situation is again the classic "those who give up freedom for security deserve neither."

gbl08ma 12y ago

I'm not saying it's a bad idea, but the thought that once HTTP is deprecated I'll need to go through extra effort to manage the myriad of devices in my LAN is bothering me. The configuration interfaces of these devices (routers, printers, IP cameras, etc.) mostly don't support HTTP. Most never had updates available and certainly never will. We're not just talking about 5+ year old devices (which despite their age still function as designed): none of the most recent routers I bought support it, except if flashed with some powerful and well maintained alternative firmware. I'm already annoyed enough by firmware update tools that only work with a specific old version of Internet Explorer... I rather not throw dozens of equipment away just because browsers started to insistently refuse HTTP connections. Let's not talk about the fact that I often spin up simple HTTP servers on my computer just to be able to transfer files to other machines on the same network, and I rather not have to worry about creating certificates (to then find out that the machines in question are "obsolete" too and don't support HTTPS?). Can we just consider HTTP to be like telnet? Old, super insecure, definitely not meant to be used by everyone daily and definitely not over the Internet, perhaps not even available/installed by default, yet super compatible and simple to implement both for the client and the server. I really hope that should mandatory HTTPS become a thing (and I'm not saying it shouldn't), an exception is added for local area connections.

Sir_Cmpwn 12y ago
Share those thoughts on the mailing list.
higherpurpose 12y ago
This just makes me think that we need is not an "improved HTTPS", but to rip out TCP/IP and encrypt everything at that level. Now we only need to convince either Google or Microsoft to implement something like that in their OS and encourage/mandate the use of it. Only these 2 matter because they are the owners of the biggest platforms. Yes Apple has a pretty big platform, too, but it's kind of irrelevant since it's a closed Apple-only ecosystem anyway so if it adopts something it doesn't mean the others will too. On the other hand, if either Android or Windows adopts something as major, I think the other one would, too. What I'm thinking is something like MinimaLT or perhaps Trevor Perrin's "Noise" if it ever becomes real. http://cr.yp.to/tcpip/minimalt-20131031.pdf http://cr.yp.to/tcpip/minimalt-20131031.pdf

zaroth 12y ago

What about devices I access via IP address which have no DNS. Like my home router, or my printer, or my iPhone when I'm connecting to an admin web interface, or my NAS...? Obviously I'm not going to setup a home domain, DNS, and SSL certs installed on all these devices just so they can use the latest HTTP/2.x features in their admin panels or user interfaces?

gurushackers 12y ago

We are the real deal in all degree of hacking. Superb Hackers have proofs with confirmation from our numerous clients around the world. Our job is done without any trace. We render the following services at an affordable price. +University grades changing +Facebook hack +email interception hack +email accounts hack +Grade Changes hack +Website crashed hack +Word Press Blogs hack +Retrieval of lost file/documents +Erase criminal records hack +Databases hack +Sales of Dumps cards of all kinds +Untraceable Ip +Bank accounts hack +Individual computers hack +Websites hack +Control devices remotely hack +Burner Numbers hack +Verified Paypal Accounts hack +Any social media account hack +Android & iPhone Hack +server crashed hack +Text message interception hack +Twitters hack +Skype hack +Credit cards hacker +We can drop money into bank accounts. We can also teach you how to do the following with our e-book and online tutorials * Hack and use Credit Card to shop online * Monitor any phone and email address * Tap into anybody's call and monitor their conversation CONTACT: gurushackers@yahoo.com