Author Topic: Shame on you, Comodo!  (Read 88205 times)

Offline Melih

  • CEO - Comodo
  • Administrator
  • Comodo's Hero
  • *****
  • Posts: 14649
    • Video Blog
Re: Shame on you, Comodo!
« Reply #15 on: June 24, 2016, 09:48:06 AM »
great insight My1..

Before start discussion..which thought process do you subscribe to please?

1)Encryption without knowing who you are encrypting for
2)Encryption with authentication (knowing who you are encrypting for)

thanks.

Offline My1

  • Comodo Member
  • **
  • Posts: 26
Re: Shame on you, Comodo!
« Reply #16 on: June 24, 2016, 10:12:49 AM »
Generally with authentication, but nobody says you need an ev for that.
Especially mostly online companies are known primarily by their domain gives less value to ev in such cases, Google, fb and Amazon all don't use ev.
Also as stated individuals CANNOT get an ev, at best and, depending on the ca they can get an ov but without the company stuff (some call this iv, identity validation) but the sad thing is that for the normal person these dont add anything in https because unless one looks at the cert details and which uneducated person does that?

Generally you also can do do authentication with dnssec, dane and a self signed cert which is, for pure domain validation even safer than a ca (but sadly browsers don't do that yet) because unlike cas where technically Anyone can sign anything in dnssec you have a clear tree structure. Even if. Us signs a cert for let's say conodo.com it won't work because of the branching structure nobody can sign something that is either above or on another branch, which makes misissuance a lot harder and we know that that happened in the past, and no matter who done it, all cas are affected by this huge problem.

Also evs can sometimes be misleading and lead to confusing stuff. I read of a case where one bank was owned by another and the owning bank was listed in the ev where people could easily thought that a rival took over the website coz not everyone knows who owns who...

Offline Melih

  • CEO - Comodo
  • Administrator
  • Comodo's Hero
  • *****
  • Posts: 14649
    • Video Blog
Re: Shame on you, Comodo!
« Reply #17 on: June 24, 2016, 11:30:28 AM »
Generally with authentication...

Great. in which use you don't need it with authentication? (i am not talking about commercial products, EV etc....merely on Encryption and Authentication, I do appreciate your input as you seem to understand background, so thank you)

Offline simbalion

  • Newbie
  • *
  • Posts: 1
Re: Shame on you, Comodo!
« Reply #18 on: June 24, 2016, 11:36:38 AM »
How can you prove it was them who made it up?

Isn't this why we have Trademark laws and courts? If they have right to it then more than happy to comply. But these kind of Intellectual copyrights can't be decided over a forum post or twitter account or trying to get your loyal but "blind" followers to bully another enterprise via their tweets. It won't work! This is not wild west and there are legal framework and courts for these kind of disputes. So lets all stop being the judge and jury and follow the law!

One a separate note, since we are talking about protecting intellectual property, there is no law protecting business models. When Lets Encrypt copied Comodo's 90 day free ssl business model, we could not protect it. Lets encrypt could have chosen 57 days, 30 days or any other number for the lifetime of their certificates. But they chose to use Comodo's 90 day Free SSL model that we established in the market place for over 9 years!!! We invented the 90 day free ssl. Why are they copying our business model of 90 day free ssl is the question! Comodo has provided and built a Free SSL model that give SSL for free for 90 days since 2007! Trying to piggy back on our business model and copying our model of giving certificates for 90 days for free is not ethical. They clearly wanted to leverage the market of Free SSL users we had helped create and establish and that's why they created exactly same 90 day free ssl offering. So why did they choose 90 day????? That is the question!

What they have is nothing new. We have been giving 90 day free certificates since 2007. Unlike them, our certificates are managed, even the free ones, so that consumers are protected. If a certificate is being used maliciously we revoke it. They don't! How is that making internet safer??? Actually consumer are less safe with their certificate because if it is used maliciously they don't revoke (Unmanaged)!

Lets get the facts right guys! We are the good guys that have been giving free SSL certificates since 2007 and managing them!

No matter what your lawyers might have convinced you of, what your doing is trying to steal your competitor's name brand. It's immoral and unethical. For a company who's business is dealing in trust validation, that raises serious concerns.

The people at ISRG created Let's Encrypt in 2014, it was their trademark then, registered or not. You know that. You knew it when you filed fraudulent trademark applications in Q4 2015.

The folks at ISRG are doing good things to improve the quality of the internet and life on planet earth. You are doing sleazy things to try and squeeze a few more undeserved dollars from users who don't know better.

Offline My1

  • Comodo Member
  • **
  • Posts: 26
Re: Shame on you, Comodo!
« Reply #19 on: June 24, 2016, 11:50:03 AM »
well here we get to the tricky point about what do we count as authentication. even a self signed cert is technically a kind of authentication since the server authenticates that he possesses this cert, the question is where it is recognized.
depending on how far we spread the definition we could say that authentication is almost everywhere (okay not in DNS but we will see more DNSSec in the future)

also the question is how far you need to do authentication. for my private server a self signed cert would be enough if I know my checksums, for example.

and yeah I have an IT job that is called "Computer Science expert - Subject Area: System integration" on the translation of my german graduation sheet (in german it's called Fachinformatiker für Systemintegration)

generally in the internet my idea everything should be HTTPS'ed and authenticated to a reasonable level
my personal computer which also runs as server has (mostly just for fun) a 16k RSA key for it's HTTPS stuff which might be a lot but when I have there direct access to my personal cloud I rather play it safe rather than that I would be sued because my music and stuff lied in the internet because of bad security.

but looking at it a bit more realistically I would say everywhere where I leave more or less personal data (even if it's just a throwaway password) I want that I know that the stuff goes to the site I want.

a part where authentication might NOT be so important are (obviously for example point to point connections (for example when I connect PC and laptop directly together for quicker file transfer there is pretty much nobody that can do anything bad so authentication wouldnt be needed there (well at least the "who" part, I still would want some checksums to check for transfer corruption and stuff but that gets us back to the first sentence), so in short when you can be otherwise sure that nothing bad can happen.

a pure read only page like a blog without comments or whatever could easily be without authentication because 1) nobody enters anything there and 2) there are probably not a likely MITM target because there is nothing to get. the worst someone could do is trying to insert ads of their (=the attacker's) own 2) do stuff that will damage the site and/or the owner's reputation, and let's get serious this isnt NEAR as profitable than going after creditcard data or other stuff.

Offline Melih

  • CEO - Comodo
  • Administrator
  • Comodo's Hero
  • *****
  • Posts: 14649
    • Video Blog
Re: Shame on you, Comodo!
« Reply #20 on: June 24, 2016, 12:18:51 PM »
well here we get to the tricky point about what do we count as authentication. even a self signed cert is technically a kind of authentication since the server authenticates that he possesses this cert, the question is where it is recognized.
depending on how far we spread the definition we could say that authentication is almost everywhere (okay not in DNS but we will see more DNSSec in the future)

also the question is how far you need to do authentication. for my private server a self signed cert would be enough if I know my checksums, for example.

and yeah I have an IT job that is called "Computer Science expert - Subject Area: System integration" on the translation of my german graduation sheet (in german it's called Fachinformatiker für Systemintegration)

generally in the internet my idea everything should be HTTPS'ed and authenticated to a reasonable level
my personal computer which also runs as server has (mostly just for fun) a 16k RSA key for it's HTTPS stuff which might be a lot but when I have there direct access to my personal cloud I rather play it safe rather than that I would be sued because my music and stuff lied in the internet because of bad security.

but looking at it a bit more realistically I would say everywhere where I leave more or less personal data (even if it's just a throwaway password) I want that I know that the stuff goes to the site I want.

a part where authentication might NOT be so important are (obviously for example point to point connections (for example when I connect PC and laptop directly together for quicker file transfer there is pretty much nobody that can do anything bad so authentication wouldnt be needed there (well at least the "who" part, I still would want some checksums to check for transfer corruption and stuff but that gets us back to the first sentence), so in short when you can be otherwise sure that nothing bad can happen.

a pure read only page like a blog without comments or whatever could easily be without authentication because 1) nobody enters anything there and 2) there are probably not a likely MITM target because there is nothing to get. the worst someone could do is trying to insert ads of their (=the attacker's) own 2) do stuff that will damage the site and/or the owner's reputation, and let's get serious this isnt NEAR as profitable than going after creditcard data or other stuff.

excellent point....lets define "authentication"....

First of all...why do we encrypt the data?
Because we don't want unintendent receipents to see the data...right? (Please confirm)
That means, to me, authentication means that I know and trust the end entity that will decrypt my encrypted code.

Fair definition of "Authentication"?

Offline My1

  • Comodo Member
  • **
  • Posts: 26
Re: Shame on you, Comodo!
« Reply #21 on: June 24, 2016, 12:40:53 PM »
yeah. seems legit.

well some thing that have no real importance and/or personal info need neither auth nor crypto, or as I said where authentication would be useless anyway e.g. in point to point connections also many places where you dont encrypt might or might not need authentication, for example I dont care if somebody sees me downloading teamviewer, VNC or whatever but I certainly dont want that that stuff gets tampered with, and in certain high performance scenarios where privacy is not an issue but it should be tamperproof auth without crypto might come in handy as well because you dont need to crypt and sign but only sign.

technically authentication even happens in normal life, for example when you speak with a friend and he has a clearly different voice you know that something is wrong.

but in internet connections authentication is important on most sites especially considering that you enter personal data at many places (even if it's just a password only for that site)

also about the intresting encrypt or not part:
with DNS and DNSSec I think the authentication is important no matter whether the stuff gets sent encrypted or not (and they are taking it seriously, they take SEVEN people every 3 months to sign the new DNS Root Zone keys while the key signing key is locked tight at all other times, and to transfer the actual key we need even more ppl, let me see all 7 crypto officers, the 2 safe admins, the internal witness plus the ceremony admin, making eleven people for that thing.

one main reason why DNSSec doesnt need to be crypted is that the DNSSec then has the problem of how we work the crypto keys and so on, which gets a it annoying, especially since I think that CAs as they are now are a bad model in general (as I said earlier anyone can certify anything) because it makes misissuances easy enough (we remember verisign/symantec, do we, oh and now bluecoat (maker of mitm hardware) has their own intermediate cert which has no restrictions aside from pathlen 0 which means they can make domain certs as they want.


also a very important point as I said the level of authentication should be reasonable. in enough cases it would be even enough if they are authenticating by their domain or even going a bit weirder a socialnetwork username/ID (obviously one that CANNOT be changed or taken again by another person) so I would know for example (important this is fictional) that a person who would go by "linuxabc" on google+ makes a software and has a forum related to that, I dont need to know the real name of that person since that isnt shown to me in most occasions anyway. in that case an identity cert would bring me nothing since I cant establish the connection between the person where I know the stuff come from (linuxabc on google+) even if I knew that the operator is called "John Smith" (especially in cases of very common names it helps even less, not to forget that the name of a person can change easily by marrying which could lead to confusion if the people) an there it would be more helpful to have the identity link by their online identity.

so the question is also where you put the "identity link" as I like to call it.

even if your name would be in the EV cert you have instead of comodo many people dont know the names of the CEOs and stuff of companies and even those can change, like it happened with google when the 2 main people went to alphabet) that's why EVs use the company name as identity link.
« Last Edit: June 24, 2016, 12:53:39 PM by My1 »

Offline Melih

  • CEO - Comodo
  • Administrator
  • Comodo's Hero
  • *****
  • Posts: 14649
    • Video Blog
Re: Shame on you, Comodo!
« Reply #22 on: June 24, 2016, 12:54:36 PM »
Now that we have established the definitions..let me pose a question to you please.

Is it doing consumers a service or disservice to put a DV cert (and i am sure you know it doesn't validate the applicant) on an ecommerce site, where a brand new user going to that site will think they are "safe" because they see the lock?

We have multiple problems in the market place.

1)People do not understand "encryption without identifying the recipient" is fallacy.
2)Browsers show "trust indicators" for stuff that has no trust in it.

Of course if i am logging onto my mail server and i know the URL/IP address (where there is a pre-established trust exist between me and the URL/IP) i might not need authentication but just encryption. You see in reality you will always need Authentication for encryption, but sometimes that authentication is Pre-established. In cases where "authentication" is pre-established, all you need is just encryption.

But at the moment, I see the use of encryption being used to "establish trust" (whether we like it or not, thats how good chunk of consumers are seeing it) where there is no authentication inside the certificate (eg: the applicant has not been identified or vetted). To me this erodes trust. Would you agree with that? My goal is to help educate people to understand how we should use "encryption" as on its own without "authentication" is pretty useless.

Offline My1

  • Comodo Member
  • **
  • Posts: 26
Re: Shame on you, Comodo!
« Reply #23 on: June 24, 2016, 01:14:00 PM »
well the fact that the lock is for trust is a thing I disagree with I mean anyone could put a lock on something so it's a bad sign (one reason why it's sad that firefox restored the locks in version 14, before that they either had a blue bar with the cert domain or a green bar for an EV company name).

about ecommerce (and many other things) we get to to the "identity link" I described earlier problem but before that let me clear one of your misconsumptions:

Quote
Of course if i am logging onto my mail server and i know the URL/IP address (where there is a pre-established trust exist between me and the URL/IP) i might not need authentication but just encryption.

stop. you would need at the very least an authentication over the domain name because otherwise you dont know who has the cert and may MITM you (e.g. company proxy) so you need at the very least an identity link to the domain and/or IP.

about about the who needs DV or should get better.

well lets kick OV out because without checking the cert you dont see anything of that so it's mostly useless for HTTPS and the average user.

for many sites I think, that sites that literally identify themselves over their domain because they are mainly in the internet and/or started there (like google or amazon) the domain name would be enough as identity link, because it's a known fact that google is called via google.com or google.de and so on, similar for amazon their addresses are publicly known and identify the company.
also as I said in some cases it can get confusing for example when I would be on amazon.de an EV cert would probably show "Amazon sarl (luxembourg)" which may look weird to people who explicitly called german amazon and dont know that the european amazon is there.

for places like banks I would say they should always be ev especially because them have sometimes long domain names which many people dont type in but get there using links and that makes it easier to hide stuff and banks are also something that primarily exists in the real life meaning that for banks and many thngs that are primarily in real life an identity lik to the actual company might make a lot more sense.

so my general Idea is what part of the identity is the best known for whate you want to offer and use that as the identity link.

Offline Melih

  • CEO - Comodo
  • Administrator
  • Comodo's Hero
  • *****
  • Posts: 14649
    • Video Blog
Re: Shame on you, Comodo!
« Reply #24 on: June 24, 2016, 02:11:41 PM »
Lock thingy: some say they trust it some say they don't. We do get A LOT of emails from consumers on daily basis complaining that they entered into a transaction with the site trusting the padlock.

Giving trusted domains as example might not show the true problem. Because you already trust the brand and that is the "pre established trust" hence going to a domain that you already trust will only require encryption. (MITM is yet another problem...).

All i am trying to do here is to create use cases where we can use "Encryption" and "Authentication".

Now you have introduced the next concept.....if a domain name is good enough "authentication/identification' who you are encrypting for.....

so here is a new question: When a person encrypting data for a domain name (with no preestablished trust) is it sufficient identification/authentication to let the user know who they are encrypting the data for?

Offline JoWa

  • Global Moderator
  • Comodo's Hero
  • *****
  • Posts: 5718
  • I believe in doubt.
    • Evolutionary history of life
Re: Shame on you, Comodo!
« Reply #25 on: June 24, 2016, 02:56:06 PM »
Its unfortunate that you chose to belittle an idea without first understanding the implications and value it brought to people when it was launched.

Lifetime of the cert matters, if you are not revoking a malicious certificate...that means end users are being harmed for the duration of that certificate.
It might have been innovative in 2007 to limit the lifetime of all certificates to ninety days, with automatic renewal. But Comodo still issues DV- and OV-certificates with a lifetime of up three years, and EV-certificates with a lifetime of up to two years¹, while the free DV-certificates are limited to a lifetime of ninety days. Automatic renewal? Don’t see it in the FAQ². I think automatic renewal is essential, but I realise it threatens a certain business model. ;)

One may see the limitation of the lifetime of the free certificate as a way to make people consider to pay for a certificate with a longer lifetime. (You spoke of business model.) Innovative?

I also noticed that the certificate from Comodo one can get for free through CloudFlare has a lifetime of seven months, and the certificate one can get through One.com is valid for one year. Why?

You say lifetime matters, but apparently it doesn’t matter if it’s ninety days, seven months, one, two or three years. ??? Instead you choose to rely on revocation. Does revocation even work? That is also why technically obsolete certificates are still in use. It’s not hard to find a certificate using SHA-1 that will expire in 2017.

To clarify. When I said “With automatic renewal, the lifetime doesn’t matter much to the user”, the user means the CA’s customer, and lifetime doesn’t matter much, it is in a practical way. No extra work is required if the lifetime is only a few days than if it is several years.

I think long-lived certificates should be deprecated. But customers demand it? If a customer wants a certificate with a lifetime of three years, offer a subscription and issue short-lived certificates with automatic renewal. :-La That’s an innovative idea in 2016. Or should that be 2006? ;)

¹ https://www.instantssl.com/compare-ssl-certificates.html
² https://support.comodo.com/index.php?/Default/Knowledgebase/List/Index/21
Ubuntu 18.10 | Chrome 73β | HTTPS Everywhere | Privacy Badger
Forum Policy | Comodo Product Help

Offline Melih

  • CEO - Comodo
  • Administrator
  • Comodo's Hero
  • *****
  • Posts: 14649
    • Video Blog
Re: Shame on you, Comodo!
« Reply #26 on: June 24, 2016, 03:03:35 PM »
Revocation work or not is not a function of CAs but Browsers. Technology is there, just needs to be deployed for a more robust revocation system.

You are trying to solve revocation problem via short term certs. Both are legit ways with pros and cons for both.

In order to understand how short the cert should be, you need to understand how fast the crime is. For example, phishing is done about 6 hours....so they only need a cert for about 6 hours to cause a damage....1 day short lived cert will allow this be perpetrated. Whereas revocation could pretty much be instant.

Offline My1

  • Comodo Member
  • **
  • Posts: 26
Re: Shame on you, Comodo!
« Reply #27 on: June 24, 2016, 03:39:55 PM »
But the problem is that we would need a good revocation system, one idea is already rolling, tge so called "must staple" for ocsp, basically in tge cert it says that a valid ocsp staple is needed (which is essentially an extremely short lived cert for the actual cert which gets directly stapled onto the tls message by the server meaning that there's no beed to chekc external servers)
But even ocsp has a lifetime so it won't be THAT instantly unless you have servers big enough to sign like every few minutes.

[at]jowa about the free certs. According to the site i linked at the bottom of page 1, there ain't just no automatic renewal but more like no renewal AT ALL (one issuance per domain)

[at]ceo i think we should split off the authorization discussion since i think it really goes quite off the nain topic.

But i think there should be the identity link in the cert that a user can relate best to and if that's not already the domain, add dv for automatic validity checks.

And i think that the user should be shown what the cert is trusting.
But the lock needs renewal. On Firefox forty something they made a change i dont really approve. All locks that aren't errors are green. I would like that they have kept grey for dv/ov.
And even ev doesn't say that the site is good legal or anything only that it belongs to a certain company and that has been thoroughly validated.
So even ev shouldn't be equal to blind trust, they should at least check on the company.

Also in most average scenarios there is no "no established trust" there is always at least one part where the user knows for definite.
If a user searches his bank on google and clicks on tge link he should get an ev because he can relate best to the bank itself.
And the browser trusts his cas which creates another trust relationship between not only the cert and the posted code and therefore the displayed content, but also between the domain and the content. In case of any extra identities listed in the cert the user can make a trust link between the content and the company listed. And even with a dv he can see this site is definitely google.com (and people know that's Google, be it ev or not)

Offline robinalden

  • Comodo Staff
  • Newbie
  • *****
  • Posts: 13
Re: Shame on you, Comodo!
« Reply #28 on: June 24, 2016, 03:41:45 PM »
Comodo has filed for express abandonment of the trademark applications at
this time instead of waiting and allowing them to lapse.

Following collaboration between Let's Encrypt and Comodo, the trademark
issue is now resolved and behind us and we'd like to thank the Let's Encrypt
team for helping to bring it to a to a resolution.

Offline My1

  • Comodo Member
  • **
  • Posts: 26
Re: Shame on you, Comodo!
« Reply #29 on: June 24, 2016, 03:45:16 PM »
[at]#28 thanks for the info, that's actually great to know and also gives the good thing that if anything changes within comodo before it runs out (and they could use the trademark) that nothing cab happen to the sleeping trademark

 

Free Endpoint Protection
Seo4Smf 2.0 © SmfMod.Com Smf Destek