I'm developing software which will be deployed using clickonce (on the website foo.com), and which will then connect to my server using WCF with an encrypted transport
So I need an SSL certificate which will :
Identify my foo.com website has really being my website
Identify the exe I deploy using clickonce as being genuine
Identify my application server has really being my application server.
I also want my SSL certificate to be signed by an authority known to the public (ie, firefox or windows won't ask the user to install the authority's certificate first !)
What SSL certificate would you buy?
I've browsed the Verisign website, the "Secure Site EV" certificate costs 1150€ a year (the "Pro" version seems useful only for compatibility with older browsers)
It sounds like you're looking for two different types of certificates:
1 - SSL Certificate - for authentication of your website/application server.
2 - Code Signing Certificate - for integrity/authentication of the exe you deliver.
Typically those are two different certificates, with two different certificate profiles. At the very least, you need one certificate with two different key usages or extended key usages.
A few thoughts in no specific order:
Check your targeted browsers, they should each have a set of preconfigured root certificates - those are the most widely recognized public certificate sources. I'd probably check both Firefox and IE. Certificate vendors known to me as big names are - Versign, GeoTrust, RSA, Thawte, Entrust. But there's also GoDaddy and many others. Anything that comes in the delivered browser as a Trusted Root Certificate, will allow you to connect to your users without additional greif.
I suggest Googling for both "code signing certificate" and "SSL certificate".
How you configure your site will determine whether or not your website is validated or your authentication server is validated. If the certificate is stored on the apps server, then your user is getting SSL encryption all the way to the server. But many sites put the SSL certificate a little farther forward - like on a firewall, and then stage a collection of apps servers behind it. I don't see a security flaw in that, so long as the networking is carefully configured. To the outside users, both configurations will look the same - they'll get the lock on their browsers and a certificate that tells them that www.foo.com is offering it's credentials.
I'm seeing pretty great deals for SSL Certificates:
- GoDaddy - $12.99
- Register.com - $14.99
But they aren't necessarily code signing certifiates. For example, while GoDaddy's SSL Cert is $12.99, their code signing certs are $199.99! That's part of many certificate vendors business models - lure you in with cheap SSL Certs, and make you pay for code signing. A case could be made that code signing certificates are relatively higher liability. But also... they have to subsidize the cheap SSL certs somehow.
Theoretically, it should be possible to make a certificate that does both code signing and SSL, but I'm not sure you want that. If something should happen, it would be nice to be able to isolate the two functions. Also, I'm pretty sure you'd have to call the certificate vendors and ask if they did this, and if they don't, having them do it will likely jack up the price quite high.
As far as vendor, things to consider:
The technology is pretty much all the same. These days, aim for a minimum of 128 bit keys, I'd probably bump it up to 256, but I'm paranoid.
Beyond browser acceptabiliy, the only reason to pay more would be name recognition. Among the paranoid security wonks, I'd expect RSA, Thawte, Verisign and GeoTrust to have very good reputations. Probably EnTrust, too. This probably only matters if you are dealing with a security focused product. I think your average user will not be so aware.
From a security geek perspective - you're only as safe as the security of your Root CA (Certificate Authority). For the truly paranoid, the thing to do would be to dig into the background material of how the company hosts its root and issuing CAs, how are they physically securited? network security? personnel access control? Also - do they have public CRLs (Certificate Revocation Lists), how do you get a cert revoked? Do they offer OCSP (Online Certificate Status Protocol)? How do they check out certificate requestors to be sure they are giving the right cert to the right person? ... All this stuff really matters if you are offering something that must be highly secure. Things like medical records, financial managment applications, tax information, etc should be highly protected. Most web apps aren't so high risk and probably don't require this degree of scrutiny.
On that last bullet - if you dig into the Verisigns of the world - the very expensive certs - you're likely to see the value. They have a massive infrastructure and take the security of their CAs very seriously. I'm not so sure about the super-cheap hosting services. That said, if your risk is low, US$300 for an SSL Cert doesn't make much sense compared to US$12.99!!
So for web site / application servers you need an SSL certificate. You do not need an EV certificate. I've used ones from QuickSSL for this, as unlike some of the other cheap certificate providers they don't require the installation of an intermediate certificate on the server - that's a no-one for me.
For signing applications that's a different type of certificate altogether (kind of, it's still an X509 certificate, but the one you use for your web site is not one you can use to sign an application). You need an authenticode signing certificate from the likes of Verisign or Globalsign. These are a magnitude more expensive than a plain old SSL certificate and require you to be an incorporated company and produce those documents.
Related
I have an online shop and I've just installed a new SSL certificate and it was free. It does seem too good to be true. I'm a very cynical type of person.
I don't know about different types of SSL, but I just need to be able to accept payment data (I'm using a PayPal add-in on Opencart).
I got my certificate from letsencrypt and they don't explain much on there website.
But if you go to my website Gwenllian-retail you will see the certificate. Can I handle financial transactions with that?
If not what type of SSL do I need?
One does not need much money or complicated software to create valid SSL certificates. I could create my own with ease, if I wanted. In fact, I have done. There is no reason to think that LetsEncrypt certificates are somehow of a wrong kind.
The question is whether people will trust those certificates, and that comes back to whether they trust the Certificate Authority (CA) that signed them. If I sign my own certificate and present that to someone as proof of my identity then that other party has no more reason to trust that the data within accurately identify me than if I just told them directly.
LetsEncrypt serves as the CA for SSL certificates it provides. I have never relied on them for a certificate, but according to hosting company DreamHost, LetsEncrypt certificates are trusted by all major browsers. (LetsEncrypt makes the same claim about itself, too.)
Again, all this trust business is mostly about authentication: whether the entity that presents the certificate (your web site) is really the entity that it says it is. It is not about the nature or quality of the encryption with which the session is secured. That comes down to the capabilities of the two endpoints, and is largely independent of the certificate.
Let's Encrypt is a well known service backed up by many big players. So yes, it's OK to use it in on your site. BUT ! SSL certificate is not everything, it's only one of many shields to protect you application.
I have a short question: why do I need a SSL certificate (I mean only the certificate not the SSL connection)?
In my case Google Chrome deteced, that the connection is encrypted and secure, but everything is red because I created the certificate by myself.
Why I need a SSL certificate, if the connection is secure?
Just because traffic to 192.168.xxx.xxx doesn't leave the boundary of your network doesn't mean that it's safe.
Especially if you have BYODs attached to the network (and even if not, you don't want to be a hard shell with a juicy interior), someone can bring a compromised laptop or phone, attach it to the network, and a virus can intercept everything going on the network (see firesheep).
So you have to assume that the network is malicious - treat your LAN as if it were the internet.
So now the question goes back - why can't I rely on a self-signed certificate (both on a local network as well as the internet)?
Well, what are you protecting against? TLS (SSL) protects against two things:
Interception - even if I MITM you (I become your router), I can't read what you're sending and receiving (so I can't read your Credit Card numbers or password)
Spoofing - I can't inject code between you and the server.
So how does it work?
I connect to the server and get a certificate signed by a CA. This CA is considered trusted by the browser (they have to go through all kinds of audits to get that trust, and they get evicted if they break it). They verify that you control the server and then sign your public key.
So when the client gets the signed public key from the server, he knows he's going to encrypt a message that only the destination server can decrypt, as the MITM wouldn't be able to substitute his own public key for the server's (his public key wouldn't be signed by a CA).
Now you can communicate securely with the server.
What would happen if the browser would accept any SSL cert (self signed)?
Remember how the browser can tell the official cert from a fake MITM cert? By being signed by a CA. If there's no CA, there's literally no way for the browser to know if it's talking to the official server or a MITM.
So self-signed certs are a big no-no.
What you can do, though, is you can generate a cert and make it a "root" cert (practically, start your own CA for your internal computers). You can then load it into your browsers CA store and you'll be able to communicate through SSL without having to go through something like letsencrypt (which, by the way, is how enterprise network monitoring tools work).
In cryptography, a certificate authority or certification authority
(CA) is an entity that issues digital certificates. A digital
certificate certifies the ownership of a public key by the named
subject of the certificate. This allows others (relying parties) to
rely upon signatures or on assertions made about the private key that
corresponds to the certified public key. A CA acts as a trusted third
party—trusted both by the subject (owner) of the certificate and by
the party relying upon the certificate. The format of these
certificates is specified by the X.509 standard.
(from https://en.wikipedia.org/wiki/Certificate_authority)
You are not a trusted CA. Basically, if you sign your own certificate then there is no one that is able to vouch that the server is truly what it is. If you had a valid, trusted third party vouch for you then the certificate would be "valid."
Having a self-signed certificate doesn't necessarily mean that the website is dangerous, its just that the identity of the server can't be verified and thus it is more risky for the vistor.
Self-created or Self Signing Certificate are not trusted by all browsers. As we know at this time all browsers are more strict towards security. Let’s be clear about something right up front, the browsers do not trust you. Period.
It may seem harsh but it’s just a fact, browsers’ jobs are to surf the internet while protecting their users and that requires them to be skeptical of everyone or everything.
The browsers do, however, trust a small set of recognized Certificate Authorities. This is because those CA’s follow certain guidelines, make available certain information are regular partners with the browsers. There’s even a forum, called the CA/B forum, where the CA’s and Browsers meet to discuss baseline requirements and new rules that all CA’s must abide to continue being recognized.
It’s highly regulated.
And you are not a part of the CA/B forum.
The better option is to obtain an SSL Certificate from a trusted certificate authority.
Here's what you need to know about a Self Signed SSL Certificate
I'm not quite understanding the necessity of certificate pinning in SSL connection establishment (to avoid Man in the Middle attacks).
SSL cert pinning requires embedding original server certificate in the host to verify with the one presented by server. what is the difference between the server certificate embedded in the host and the one presented by server to be validated by client?
What is that I am missing here?
what is the difference between the server certificate embedded in the host and the one presented by server to be validated by client?
There should be none and that's exactly the point of certificate pinning.
Without certificate pinning an application commonly accepts any certificate which matches the requested hostname and is issued by a locally trusted CA (certificate authority). Given that there are usually more than 100 CA in the local trust store it is sufficient that one of these got successfully attacked as in the case of DigiNotar in 2011. Thus it makes sense to limit the certificate you accept to a specific one, i.e. pinning.
Besides the certificate pinning by comparing the certificate received with a locally stored certificate there are other ways of pinning: for example one might just check against a fingerprint (hash) and not the full certificate. In case the certificate can expire it might be more useful to check only the public key and not the whole certificate because the public key is often kept on certificate renewal. Or one might pin to a specific CA which one considers trusted to issue certificates for this domain.
Note that to understand pinning you might need to understand how the authentication of the server works. One part of this is that the server certificate is validated (hostname, expiration, trust chain ...). But this is not enough since the certificate itself is public, i.e. everybody can get it and could send it inside the TLS handshake. Thus the other major part of the authentication is that the server proves that it is the owner of the certificate. This is done by signing some data using the private key matching the certificate. Since only the owner of the certificate should have the private key this proves ownership. Because of this anybody could embed the servers certificate for pinning but only the server itself can prove ownership of the certificate.
What is SSL pinning
Applications are configured to trust a select few certificates or certificate authority (CA), instead of the default behaviour: to trust all CAs that are pre-configured on the device/ machine. SSL pinning is not required.
Why use SSL Pinning (Why not to)
In many cases, the certificate returned by a server could be tampered as long as any Root (or intermediate root) CA was compromised (happens very rarely). Threat actors could use this compromised CA to generate a certificate for your website, and show visitors their website instead. This is bad. SSL pinning was designed to prevent this in some cases, but there are better ways (IMHO).
Having said that, I don' t know any website which uses SSL pinning so SSL pinning seems primarily discussed for mobile apps. It seems like SSL pinning only works when you can trust the source of the application (e.g. App Store, Play Store) Why? Because if you have to visit a website to get the cert, by then its too late (you might have already used a dodgy cert and accessed the fake website or was MITM'd). Therefore, it seems like the benefits Steffen mentioned are not so compelling, especially when there are better solutions already:
Better solution
I'm not sure if any-CA-compromise is a threat vector, even for banks. Instead, banks and other security conscious organisations will pick their CA wisely, and also configure a CAA record.
By using a CAA DNS record, they can restrict clients (e.g. browsers, mobile apps) to trust only certain certificates when accessing their specific website.
They pick the CA and create a cert only from this CA
They will have a backup plan for if a CA is compromised. Don't want to go into that here, but the backup plan for CAA records is IMHO much better than that of SSL pinning.
For example, Monzo.com (I used whatsmydns to find this) has a CAA record which restricts certificates to only 4 CAs (digicert, amazon, comodoca, buypass):
0 iodef "mailto:security#monzo.com"
0 issue "amazon.com"
0 issue "buypass.com"
0 issue "comodoca.com"
0 issue "digicert.com"
0 issue "letsencrypt.org"
0 issuewild "amazon.com"
0 issuewild "comodoca.com"
0 issuewild "digicert.com"
0 issuewild "letsencrypt.org"
These are popular CAs which people trust, we hope they don't let us down. If they do, the whole internet would be a free for all. The only way to prevent this is to be your own CA/ use self-signed certificates.
Summary
I don't see how SSL pinning will become ubiquitous, especially since it adds more overhead (maintenance regarding ssl expiry, or trusting one CA anyway - SPoF, or emulating what a CAA record does but with additional code/ maintenance burden). It also only supports your pre-installed applications, not websites.
I have been reading up on the technical basics of how SSL works (which was surprisingly hard to find inside the ocean of laymen/non-technical articles/tutorial/videos out there). I have 3 small questions that in and of themselves felt too small to clutter SO with but as a whole I think provide some insight into how SSL works and address issues that don't seem to be well-documented:
Why (not when or how!) do SSL certificates expire? These are just public/private key pairs operating on a cipher/algorithm like AES. I assume there's a financial/business incentive behind the scenes here?!?
How many SSL certificates does an organization need? And before you say "that depends on your organization", I guess at the core of this question is: what driving factors make a company say, oh, I guess we're going to need another cert, or 10 more certs, etc. In other words: why is 1 cert often not sufficient for an organization??
Why does a company ask a CA for a root certificate and then get child certificates off of that root? What benefits does this "Certificate Tree" provide? (As opposed to just getting separate certs.)?
Thanks in advance!
1) Why do SSL certificates expire?
When a certificate expires, you're basically saying that this public/private keypair has been abandoned. Technically, you can still use this certificate to encrypt data, but the expiration date is there to mitigate revocations among other things. Additionally, however, in the X.509 spec there are specific reasons outlined for expiration:
4.1.2.5 Validity
The certificate validity period is the time interval during which the
CA warrants that it will maintain information about the status of the
certificate.
CAs publish revocation status information about a certificate and that means they need to keep track of them. When a certificate expires, the CA has done their part for the term of the certificate and stops tracking information for that certificate. You are essentially paying the CA to say with authority that this certificate is valid.
There are other reasons for expiration too. If I was still using a certificate signed in 2002 (which would be possible), the level of encryption probably wouldn't be up to standards used today. By setting an endpoint for the certificate, you are also setting a date on which you need to upgrade.
Now, of course, I don't think you can deny one of the biggest motivators behind the expiration is money [citation needed], but there are at least some technical and reasonable ideas behind it.
2) How many SSL certificates does an organization need / what driving factors help them decide?
It does depend on your organization. A traditional SSL certificate is matched to a domain name. However, anything can be signed with a key pair (developer certificates, etc.). So, for SSL, it'll depend on the number of domains you want to protect. For a traditional cert, www.domain.com and example.domain.com are completely different entities. There are other types of certs that can purchased, like wildcard certs, etc. that will depend on the needs of your business. Seriously, you can get incredibly complex or incredibly simple. Here's a rundown on some of the basic and different types for protecting a website: SSL Certificate Types
3) What benefits does [having a] "Certificate Tree" provide, as opposed to just getting separate certs?
You are basically saying that you trust this CA to generate certificates. That's why browsers have to have the root CA installed to accept a certificate. They are saying, "I trust this authority has only signed certificates for valid and trusted sources."
In practice, it ends up not being the case as a lot of CAs don't rigorously check who they are giving certificates to before issuance. Not always, but it does mitigate some of the danger. The problem is when the CA root certificate private key is compromised because then anyone can fake a legitimate certificate.
Hopefully this answers some of your questions.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I would like to have the authentication and registration parts of my website encrypted (for obvious reason). This site is currently and older site which some friends and I started in middle school and still use today. I may or may not register it to be a Non-Profit Organization in the near future, but either way, a CA costs money and the organization doesn't have any and we are currently college kids.
Verisign is unreasonable and GoDaddy is $30/year. GoDaddy isn't too unreasonable, and I think their certs are accepted by most web browsers. The thing with GoDaddy is that I don't know why they have different SSL products (i.e.: why is it cheap to not verify me? does this have any implications on the cert and how the browser treats it if it just contains a domain name?)
Also, is there an issue with using my own cert? Could the login page be http, and have a line stating that I use a self-signed cert and here is it's fingerprint and then post the form to an https page? Safari's method isn't too bad or sound too scary. I'm afraid, however, that firefox 3's method will scare people away and give me a tonne of emails saying that my site is being hacked or something. I don't know how IE responds to self-signed certs. (There is also the issue of why pay for something I can create myself with no effort, but I'm not going to pose the philosophical part of it, this is a more practical question.)
In sum, do I give GoDaddy $30 a year or do I just tell people in a small paragraph what I'm doing and give the few people that will actually want my fingerprint it?
Edit: Some on a forum I was reading for more info mentioned that GoDaddy certs are only given if it's on a GoDaddy server, which this isn't. Two things: (1) is this true? and There are other CA's at about the same price, so the argument should still be the same.
There's a common misconception that self-signed certificates are inherently less secure than those sold by commercial CA's like GoDaddy and Verisign, and that you have to live with browser warnings/exceptions if you use them; this is incorrect.
If you securely distribute a self-signed certificate (or CA cert, as bobince suggested) and install it in the browsers that will use your site, it's just as secure as one that's purchased and is not vulnerable to man-in-the-middle attacks and cert forgery. Obviously this means that it's only feasible if only a few people need secure access to your site (e.g., internal apps, personal blogs, etc.).
In the interest of increasing awareness and encouraging fellow small-time bloggers like myself to protect themselves, I've written up a entry-level tutorial that explains the concepts behind certificates and how to safely create and use your own self-signed cert (complete with code samples and screenshots) here.
The SSL certificate solves two purposes: encryption of traffic (for RSA key exchange, at least) and verification of trust. As you know, you can encrypt traffic with (or without, if we're talking SSL 3.0 or TLS) any self-signed certificate. But trust is accomplished through a chain of certificates. I don't know you, but I do trust verisign (or at least Microsoft does, because they've been paid lots of money to get it installed in their operating systems by default), and since Verisign trusts you, then I trust you too. As a result, there's no scary warning when I go to such an SSL page in my Web browser because somebody that I trust has said you are who you are.
Generally, the more expensive the certificate, the more investigating that the issuing certificate authority does. So for the Extended Validation certificates, the requesters have to submit more documents to prove that they are who they say they are, and in return they get a bright, happy green bar in modern Web browsers (I think Safari doesn't do anything with it quite yet).
Finally, some companies go with the big boys like Verisign purely for the brand name alone; they know that their customers have at least heard of Verisign and so that for people shopping on their online store, their seal looks a little less sketch-ball than, say, GoDaddy's.
If the branding is not important to you or if your site is not prone to phishing attacks, then the cheapest SSL cert that you can buy that has its root installed in most Web browsers by default will be fine. Usually, the only verification done is that you must be able to reply to an e-mail sent to the DNS's administrative contact, thus "proving" that you "own" that domain name.
You can use those cheap-o certificates on non-GoDaddy servers, sure, but you'll probably have to install an intermediate certificate on the server first. This is a certificate that sits between your cheap-o $30 certificate and the GoDaddy "real deal" root certificate. Web browsers visiting your site will be like "hmm, looks like this was signed with an intermediate, you got that?" which requires may require an extra trip. But then it'll request the intermediate from your server, see that it chains up to a trusted root certificate that it knows about, and there is no problem.
But if you are not allowed to install the intermediate on your server (such as in a shared hosting scenario), then you are out of luck. This is why most people say that GoDaddy certs can't be used on non-GoDaddy servers. Not true, but true enough for many scenarios.
(At work we use a Comodo certificate for our online store, and a cheapo $30 GoDaddy cert to secure the internal connection to the database.)
Edited in italics to reflect erickson's insightful clarifications below. Learn something new every day!
Get a certificate from Let's Encrypt, a free CA this new decade, which is widely supported by browsers.
I haven't tried them yet, but StartCom was mentioned in a response to a similar question. Apparently you can get a one year certificate for free, and it's accepted by Firefox 3.
Even if you have to pay, I would suggest using a CA rather than self-signed certificates. Some people won't see your explanation, and a fake site could post their own fake certificate's fingerprint just like you propose. I doubt the average user knows what a certificate fingerprint is or how to check it.
Instead of creating a self-signed cert, create a self-signed CA, and sign your HTTPS certificate with that. It's easier to ask users to install a CA than a single server cert, and you can create new certs (eg. for subdomains, or to update expired certs) without users having to install a server cert again.
You can then decide later whether it's worth the $30 to switch from a cert signed by your own CA to the same cert signed by GoDaddy or whoever.
Either way, don't have an HTTP page with a form posted to HTTPS. The user cannot see that that's where it's going; they'd have to view source to check the form hasn't been hijacked to point elsewhere and no-one's going to do that. You would have to have an HTTP front page with the CA link and a separate link to the HTTPS login form.
Asking users to install a CA with a cert downloaded via plain HTTP is a bit naughty: if there were a man-in-the-middle they could replace your CA on the fly and hijack the ensuing HTTPS connections. The chances of this actually happening are quite low as it would have to be a targeted attack as opposed to plain old automated sniffing, but really you ought to be hosting the CA download link on some other HTTPS-protected service.
Customer acceptance is a matter only you can answer, knowing who your users are. Certainly the Firefox interface is excessively scary. If CAs like GoDaddy are down to $30 these days I would probably go for it; it used to be a lot, lot worse.
Assuming support on old and niche browsers is not much of an issue, just go for the cheapest CA available. You are supposed to be paying to have the CA properly verify who you are, but in practice that's not the way it works and it never has been, so paying extra for more thorough checks gets you almost nothing. Verisign's extortionate prices survive through corporate inertia alone.
CAs are there to receive money for doing nothing but owning a few hundred bits of private key. The identity-verifying stuff that was supposed to have been part of the CA mandate has been moved to EV certificates. Which are even more of a rip-off. Joy.
Self-signed certificates are insecure. Yes, really. "At least it's encrypted" isn't helping at all. From the article:
World-class encryption * zero authentication = zero security
If your website is for you and a few of your friends, then you might create your own CA and distribute your certificate to friends.
Otherwise either get a certificate from known CA (for free) or don't bother with self-signed certificates at all, because all you'd get is a false sense of security.
Why just encrypted traffic is not secure? You're always allowing the other end to decrypt your traffic (you have to, otherwise you'd be sending gibberish).
If you don't check who's on the other end, you're allowing anybody to decrypt your traffic. It doesn't make a difference if you send data to an attacker securely or not securely — the attacker gets the data anyway.
I'm not talking about checking whether e.g. paypal.com belongs to a trustworthy financial institution (that's a bigger problem). I'm talking about checking whether you're sending data to the paypal.com, or just to a van around the corner that sends a certificate saying "yeah, I'm like totally paypal.com and you have my word that it's true!"
I just finally broke down and switched my server from self-signed to a GoDaddy cert last night and it wasn't that big a deal, aside from their process not being as clear as it could be. $30/year is a reasonable cost and using the cert on a non-GoDaddy server is not an issue.
If you're going to be talking SSL to the public, get a real cert signed by a real CA. Even if you're working for minimum wage, you'll save more than $30/year worth of wasted time in dealing with user fears or distrust, and that's even before considering any possible lost revenue due to them being scared away from your site.
To answer your question about Internet Explorer, it will warn users about any site whose certificate is not signed by an IE-known (unfortunately called "trusted") CA. This includes for your own CA and for self-signed certificates. It will also make a warning if the domain in the certificate is not the one being accessed.
If this is a private site, you may not care so long as you are getting link-level encryption (and are you that fearful of someone sniffing your traffic?). If there is public access and you want SSL, then get a signed certificate from a recognized CA, as others have already advised.
If that van around the corner is capable of hijacking your internet connection already, you've got worse problems than self-signed certificates.
Banks should use client certificates for authentication. That would make it impossible for that van to do anything.... since it doesn't have the banks private key.
Self-signed certs are perfectly fine... assuming your internet connection hasn't been compromised. If your connection has been compromised... you're probably dogged anyway.