November 5th, 2013, 06:38 PM
Self-signing as a CA?
greetings! this is my 1st message here.
i am currently learning about both the ssl and encryption technology that servers are using and also the infrastructure of 'corporate dominance' that has been created behind the scenes of the web to implement the ssl cash cow. (can you see where this is going yet? lol)
i have created a key pair and certificate using openssl for my website and can sign-in to my site correctly (without a warning page being shown) once i have installed the certificate into the browser's list of CAs.
as a way of distributing the certificate to site users i have uploaded the .crt file to a trusted file sharing site and so visitors can download the file via https from that site to their pc (maintaining 'trust') and then install that file into their browser manually.
as far as i am aware, that is no less secure than paying for a certificate from a corporation. the only downside is that my site is not listed by default as a CA in web browsers and so i need to put an explanation of this on my site for visitors to realise why i am asking them to download and install a file that other sites don't.
am i missing something here? has anyone here experimented with this approach?
November 5th, 2013, 08:28 PM
Yes: The whole point of certificates.
Originally Posted by ura_soul
When your visitors try to connect to your website for the first time and see a download link to a certificate, how do they know that the link hasn't been tampered with during transport? They'd have to verify the identity of the server, right? And how do they do that? By making sure the link hasn't been tampered with and actually points to your certificate. So your poor visitors either run into an infinite loop -- or they have to give up and simply accept any data they get, at which point the whole exercise becomes useless.
You can't verify the identity of something based on the identity of this same thing. It's like me telling you: "I'm Bill Gates. You can take my word as Bill Gates."
So the security of your setup is exactly zero. It's actually below zero, because you and maybe your users think that it's secure.
A chain of trust requires some kind of bootstrapping. In the traditional CA system, it all starts with you trusting, say, Firefox. Firefox trusts some root CAs. Those root CAs may trust sub CAs. And those CAs finally verify the identity of a particular website. If you accept this chain of trust, then you can accept the identity of the website.
Since you reject this model, how does your bootstrapping work instead? If this website is only for a limited set of users, and you know each other personally, then you could actually sit down together and exchange the fingerprint of the certificate -- or at least do that on the phone. This would be very secure. However, if the site is for the general public, there's no way around an external CA. This doesn't have to be one of the big companies. For example, StartCom offers standard certificates for free, and it's preinstalled in most browsers. And there's CAcert which offers free certificates using a web of trust. Since you have to meet the person verifying you, this again is very secure -- but most browsers don't have CAcert preinstalled.
It all depends on how much security you want and how much effort you're willing to invest.
Last edited by Jacques1; November 6th, 2013 at 04:25 AM.
November 6th, 2013, 03:05 PM
thanks for responding here.
i think you missed the part where i said that the certificate is hosted on a secure file sharing site (in this case ubuntuone.com - so the connection between the user and the server that hosts the certificate is as secure as any other secure connection).. do i 'know' the coders and admins of ubuntuone? no.. so this is not the best solution. this does however, bypass the issue of having a 'trusted' connection. i think.
i have looked at the free options. one was for usa only.. and i am not located @ usa.. the other was based in israel- i spoke with them directly via phone and concluded I do not trust THEM!
i just found a video which claims to show that the entire CA system and browser security is hugely flawed and broken.. its a couple of years old now.. though i see no comments saying that these flaws have been fixed.. perhaps there are too many people happily spying on all 'secured' data to want to 'fix' the situation.
i am unable to share the link here due to forum rules.. however you can find the video on youtube by searching for:
DEFCON 17: More Tricks For Defeating SSL
November 6th, 2013, 05:09 PM
How is Ubuntu One "secure" in the context of certificates? They don't verify SSL certificates, do they?
If your email address at Ubuntu One happens to be something like email@example.com, then you could kinda sorta abuse Ubuntu One as a makeshift CA. Your users would at least have a slight indication that the certificate may comes from you.
But this model is even less secure than the crappiest standard certificate, it's 10 times as inconvenient for your users, and it's more than obscure. Why on earth would any user go through that procedure? Just so that you can save a few bucks?
Sorry, but this is nonsense. You can either aim at high security for experienced users (CAcert or personally exchanging the fingerprint). Or high convenience for average users (standard CAs). But lots of effort for poor security isn't a good selling point. Ubuntu One isn't even a proper keyserver. They neither have the motiviation nor the infrastructure for protecting certificates, because that's simply not their business.
C'mon, don't badmouth the traditional CA system when your own approach is even worse.
Originally Posted by ura_soul
If you're waiting for perfect security, you can wait forever. There's no such thing, neither on the Internet nor in "real life". Trust in particular is mostly a social problem, not a technical problem. There's no definite solution.
However, there are plenty of good ideas and pragmatic approaches. Don't like the top-down CA system? Use a distributed model like the already mentioned CAcert or projects like Monkeysphere. Worried about a particular SSL certificate? Contact the webmaster and have them confirm the fingerprint. Afraid of forged certificates from the big CAs floating around? Use certificate pinning. And so on.
Everybody can choose their own security level. The more effort you're willing to invest, the more security you can get. Your idea, unfortunately, isn't helpful with that.
November 7th, 2013, 01:13 PM
to be clear here.. this idea of hosting the certificate on another server is not one i created - i read it from another idea creator online and is one that i am exploring the effectiveness of. i agree here that the process of manually downloading and installing a certificate is not optimal. while i do have experience of coding and computer science, i have not studied ssl before and the mountains of marketing and flawed implementations has not made this as simple an exploration as it may have been.
i am grateful for observing the videos i quoted on youtube since they clearly reveal the flaws in the commonly used system, such that the system is shown to be not fit for purpose. i urge anyone involved with computer security to watch the speakers there and learn through them - they cover topics that are effectively deleted from the mainstream so that 'the trust industry' doesn't lose 'face'. (money).
while researching keyservers i found that ubuntu has one.
though i have no particular reason to use ubuntu over some other server.. i just picked them as a test since i could.
i am not badmouthing here, i am acting based on clear evidence that their approach has failed. my method here is simply a first step, for many reasons it is not 'the' solution.
this project (convergence) appears to be a fairly solid replacement evolution of the model created by ones who have thoroughly researched, broken the existing system, spoken to it's original designer and intelligently created a de-centralised replacement: convergence . io
looking at monkeysphere, they appear to be approaches to resolving similar issues, though they use different solutions as far as i am seeing so far.
the only security that is offered is that they provide a method of connecting via the certificate chains back to a root and thus theoretically offer a way of a client connecting to your certificate via https without triggering an 'untrusted' warning and thus maintaining 'trust'. they 'should' be able to download the file that i have uploaded to ubuntuone, since both my upload to ubuntuone and their download from ubuntuone ran through a 'secure' connection that is trust certified. the trust verification is in the verification of ubuntuone that the client will do with a CA, not in the verification of the version of my certificate that is stored by ubuntuone.
Originally Posted by Jacques1
i am unclear on why this approach is less secure than the 'cheapest' certificates.. possibly i am missing some details on what this process involves.
Originally Posted by Jacques1
as far as i am aware, the connection that is made between the client and the ubuntuone secure page is as strong as any that would be made via the use of a cheap certificate that was purchased for my own site and thus the only flaw would be if ubuntuone (or another server/site) were to unscrupulously change my certificate or if they got hacked. which is not so different to what might happen to one of the 'root' / 'trusted' CAcerts; why would i trust these CA corporate entities more than any other entity, when i have never met them? just because they say they are trustworthy and 'trust is their job'? that is insufficient... that is the type of claim politicians make and does not stop them acting psychopathically.
i see now that CAcert is not only for the USA.. i thought that when i looked at them long ago that they were only for that location and i could not use their service. i will investigate them again and see if they are a viable option for me.. thanks for the re-minder.
ideally they wouldn't.. however, the motivation for doing so may be as a result of realising the truth of the flaws in the current system and a dislike of being deceived by the 'trust industry' and not wishing to support the imbalances of a pyramid scheme masquerading as a secure and beneficial service. my website is not a shop.
i agree on this completely.. the purpose of my website is to assist in the re-balancing that will evolve the society to a place of unified real trust that is of the heart. the same drive for automation that powers the trust industry, is the same drive that stops me posting urls in this thread and the same that subtly enforces the 'rule' that thoughtlessness and thus feeling-less-ness and thus 'heart-less-ness' will determine our experiences and movements.
November 7th, 2013, 02:14 PM
on closer inspection of CAcert i see that my early thought about them being based @ usa was due to my ignorance of the situation and my hurry and i jumped to the conclusion that CA was California. lol.
November 7th, 2013, 02:36 PM
The issue simply comes down to who do you trust? By installing a root certificate as trusted, you are opening yourself up to automatically trusting any certificate based on that root certificate. As such, you need to have trust that whoever issues that root certificate is not going to f* you and sell fake certificates to hackers, thieves, etc.
Say you actually convince someone to install your certificate. Once installed you could trick them into visiting any number of fake sites while letting them appear legit. Just get them to install some malware on their system which intercepts requests for the sites you want to take over and redirect them to your own servers. Take paypal for example. You'd setup your own server with a phony version of paypal complete with a SSL certificate based on your root certificate. Have your malware intercept and redirect any requests for *.paypal.com to your server. Because they have your root certificate as a trusted CA, the browser would not flag the connection as questionable and everything would appear legit, green security bar and all. They login, you steal the credentials, login to the real site and steal their money.
You simply are not going to be that trustworthy to the general population for them to take that risk and install your certificate. The large CA's have that level of trust because a large number of people reviewed their policies/practices and deemed them trustworthy. There is also legal action that can be taken against the companies should they fail to live up to the people's trust.
Recycle your old CD's, don't just trash them
If I helped you out, show some love with some reputation, or tip with Bitcoins to 1N645HfYf63UbcvxajLKiSKpYHAq2Zxud
November 7th, 2013, 03:06 PM
You don't understand the concept of certificates and what's necessary to verify them.
You realize that anybody can create any certificate, right? If you tell me your domain, I'll make a perfectly valid TLS certificate for your domain with my key. I can then start distributing the certificate. I can upload it to Ubuntu One and tell everybody that I'm the webmaster of your site and that they should install my certificate. And nothing would stop me.
What does that tell us? A certificate by itself means nothing. It's as trustworty as a home-made ID card.
A certificate only becomes valuable if somebody verifies and confirms the data, in particular the ownership of the certificate. It's not enough to simply claim that you're the webmaster of some website. You have to prove it. Commercial CAs usually generate a long random number, send it to firstname.lastname@example.org or a similar address and ask you to confirm the code. If you can do it, you most probably have access to the webmaster email account. And this means you most probably are the webmaster.
Then they sign the certificate, which bundles the data and creates a verifiable and (practically) unforgeable confirmation by this very CA.
See the process? A certificate must always be verified.
Where's this verification in your model? No, HTTPS doesn't help you with that. An encrypted connection doesn't prevent people from lying. Verification means sending a challenge code to email@example.com or taking similar actions. If there's no such instance, you're doing it wrong.
The funny thing is that your whole model actually relies completely on one of the evil CAs. Guess who's responsible for the TLS certificate of Ubuntu One: GoDaddy. *lol*
So even if your email address at Ubuntu One is firstname.lastname@example.org (which you still haven't confirmed), you've recreated the very pyramid model you hate so much. But instead of relying on a single CA and a proper signature, you rely on GoDaddy plus Ubuntu One plus an unsteady distribution system.
I repeat: The trustworthiness of this is zero. If any of your users are actually willing to accept it, they'll probably accept anything. So the next best social engineer will get them to install some fake certificate.
I don't wanna put you down, but I think your goal of revolutionizing the CA system might be a bit overambitious. Inventing your own security protocol is generally a very bad idea unless you happen to be a renowned security expert.
Long story short: Go with CAcert or any known CA.
I'm pretty sure that he/she was talking about the users installing a web certificate. If this is actually about a custom root certificate, it would indeed be even more insane.
Last edited by Jacques1; November 7th, 2013 at 03:11 PM.
November 7th, 2013, 03:38 PM
i see that, yes. the issue for me is that i don't trust the ones who i am being pressured to trust through the 'herd mentality' of 'we say they're ok and we've convinced enough others through our evolved potential trojan malware delivery systems (aka web-browsers) to accept that they're ok' so you are going to need to trust us too or you can't use the internet. which is essentially what is occurring every day without most of us noticing. "nice work if you can get it"
Originally Posted by kicken
i see that possibly CAcert is a usable replacement to some extent - depending on the corruption or non-corruption of that community.
so the awesome model of verification here is 'access to an email address' associated to a domain name? lol
Originally Posted by Jacques1
how is that any more secure than me placing a link on a public page on my website to a secured server that hosts my key (while i used the example of ubuntuone it could be any other server obviously.. it could be youcantrustus.superhonestly.woo). both imply that i have got access to my server. if i have access to place a link in the correct place on my server to my site's certificate, then i most likely have access to the emails too.. no? or at least, the possibility is highly likely. i don't see why access to email equates to greater evidence of authenticity than a link on a webpage. in fact, if i am not using encrypted and secured emails then the link on the webpage is possibly more trustworthy if i AM using SSH to login to the server to upload code.
yes, i appreciate that my approach here is not revolutionary and does not remove the pyramid issue.. so it is only really a slightly symbolic step in the right direction, which, for me is significant in that my site does not use money and so any fees are a challenge, even if they are only relatively small. if i can only get a crappy level of encryption for a small fee from an 'authority' but can get a 2048 bit certificate self generated for free, then i increase the encryption level by using my own free one in place of the comodo or other low price one.
Originally Posted by Jacques1
fyi, i am not likely to use this approach now that i realise that the free CAcert option is possible and also that a complete replacement for the CA system is on the horizon, so to speak.
November 7th, 2013, 03:52 PM
hmm.. i appreciate that the verification may prevent some man in the middle attacks if the CA is not corrupted and their systems are solid. i see that i missed that i am confusing the issue of mitm attack with the issue of server security in these hypothetical observations..
in that the attacker does not need to attack the server in a mitm attack, yet they would do to gain access to the email address used for validation.
what is motivating me sub-consciously here is that in the videos i pointed to they showed how it was very easy to get wildcard ssl certificates for use in mitm attacks from 'real' CAs.. since their own code was so insecure. this was done 3 years or so ago, so that may have changed.. yet the exploits in the broken ssl protocol design have not been updated with a new version as far as i am aware.
you would need to watch the videos to appreciate what i am saying here.
November 8th, 2013, 12:17 AM
so for now i am using CAcert.. so far so good.
November 8th, 2013, 12:51 AM