Skip to main content
clarity - removed the unnecessary intro sentence
Source Link
schroeder
  • 132.1k
  • 55
  • 307
  • 348

Speaking roughly, but precisely : it can jeopardize your experience just like having a sex with AIDS-infected hooker - it will be ruined forever. Speaking in more details - youYou must take a deep look at the certificate you're offered to trust. Every certificate has it's own "permitted usage" flags - and you should examine them carefully. Take a further reading here and there - it will give you the whole idea about a certificate types.

UPDATE: You must suspect not the fact, that the certificate you're trusting is not trusted by you yet, but the abilities of this certificate  : can it be just a webserver's self-signed one, or it can be a full-featured CA and can sign other cerificatescertificates. The attack vector when you're giving someone your certificate to be trusted is not just make them trust it, but allow you to alter their trusts further through that certificate once it's trusted. That's my point. 

For example, you can be given a self-signed HTTPS certificate on a website, so far so good, but with CA capabilities too  : so you're trusting it and securing your connection, but when you'll try to go to - let's,let's say for example - gmail,gmail.com to check your mail, a MitM attack may be attempted with a certificate identical by text values to the original GMail one, but signed with that same certificate of a website and because you've just trusted it, your. Your browser will show no warning, because it's validated successfully.

Speaking roughly, but precisely : it can jeopardize your experience just like having a sex with AIDS-infected hooker - it will be ruined forever. Speaking in more details - you must take a deep look at the certificate you're offered to trust. Every certificate has it's own "permitted usage" flags - and you should examine them carefully. Take a further reading here and there - it will give you the whole idea about a certificate types.

UPDATE: You must suspect not the fact, that the certificate you're trusting is not trusted by you yet, but the abilities of this certificate  : can it be just a webserver's self-signed one, or it can be a full-featured CA and can sign other cerificates. The attack vector when you're giving someone your certificate to be trusted is not just make them trust it, but allow you to alter their trusts further through that certificate once it's trusted That's my point. For example you can be given a self-signed HTTPS certificate on a website, so far so good, but with CA capabilities too  : so you're trusting it and securing your connection, but when you'll try to go to - let's say for example - gmail.com to check your mail, a MitM attack may be attempted with a certificate identical by text values to the original GMail one, but signed with that same certificate of a website and because you've just trusted it, your browser will show no warning, because it's validated successfully

You must take a deep look at the certificate you're offered to trust. Every certificate has it's own "permitted usage" flags - and you should examine them carefully. Take a further reading here and there - it will give you the whole idea about certificate types.

UPDATE: You must suspect the abilities of this certificate: can it be just a webserver's self-signed one, or it can be a full-featured CA and can sign other certificates. The attack vector when you're giving someone your certificate to be trusted is not just make them trust it, but allow you to alter their trusts further through that certificate once it's trusted. That's my point. 

For example, you can be given a self-signed HTTPS certificate on a website, so far so good, but with CA capabilities too: so you're trusting it and securing your connection, but when you'll try to go to,let's say for example,gmail.com to check your mail, a MitM attack may be attempted with a certificate identical by text values to the original GMail one, but signed with that same certificate of a website and because you've just trusted it. Your browser will show no warning, because it's validated successfully.

added 996 characters in body
Source Link
Alexey Vesnin
  • 1.6k
  • 1
  • 8
  • 11

Speaking roughly, but precisely : it can jeopardize your experience just like having a sex with AIDS-infected hooker - it will be ruined forever. Speaking in more details - you must take a deep look at the certificate you're offered to trust. Every certificate has it's own "permitted usage" flags - and you should examine them carefully. Take a further reading here and there - it will give you the whole idea about a certificate types.

UPDATE: You must suspect not the fact, that the certificate you're trusting is not trusted by you yet, but the abilities of this certificate : can it be just a webserver's self-signed one, or it can be a full-featured CA and can sign other cerificates. The attack vector when you're giving someone your certificate to be trusted is not just make them trust it, but allow you to alter their trusts further through that certificate once it's trusted That's my point. For example you can be given a self-signed HTTPS certificate on a website, so far so good, but with CA capabilities too : so you're trusting it and securing your connection, but when you'll try to go to - let's say for example - gmail.com to check your mail, a MitM attack may be attempted with a certificate identical by text values to the original GMail one, but signed with that same certificate of a website and because you've just trusted it, your browser will show no warning, because it's validated successfully

Speaking roughly, but precisely : it can jeopardize your experience just like having a sex with AIDS-infected hooker - it will be ruined forever. Speaking in more details - you must take a deep look at the certificate you're offered to trust. Every certificate has it's own "permitted usage" flags - and you should examine them carefully. Take a further reading here and there - it will give you the whole idea about a certificate types

Speaking roughly, but precisely : it can jeopardize your experience just like having a sex with AIDS-infected hooker - it will be ruined forever. Speaking in more details - you must take a deep look at the certificate you're offered to trust. Every certificate has it's own "permitted usage" flags - and you should examine them carefully. Take a further reading here and there - it will give you the whole idea about a certificate types.

UPDATE: You must suspect not the fact, that the certificate you're trusting is not trusted by you yet, but the abilities of this certificate : can it be just a webserver's self-signed one, or it can be a full-featured CA and can sign other cerificates. The attack vector when you're giving someone your certificate to be trusted is not just make them trust it, but allow you to alter their trusts further through that certificate once it's trusted That's my point. For example you can be given a self-signed HTTPS certificate on a website, so far so good, but with CA capabilities too : so you're trusting it and securing your connection, but when you'll try to go to - let's say for example - gmail.com to check your mail, a MitM attack may be attempted with a certificate identical by text values to the original GMail one, but signed with that same certificate of a website and because you've just trusted it, your browser will show no warning, because it's validated successfully

Source Link
Alexey Vesnin
  • 1.6k
  • 1
  • 8
  • 11

Speaking roughly, but precisely : it can jeopardize your experience just like having a sex with AIDS-infected hooker - it will be ruined forever. Speaking in more details - you must take a deep look at the certificate you're offered to trust. Every certificate has it's own "permitted usage" flags - and you should examine them carefully. Take a further reading here and there - it will give you the whole idea about a certificate types