Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Computing > Computer Security > successfully installed openssl on hosted server - host says there i sno security unless I buy separate certificate - is that right?

Reply
Thread Tools

successfully installed openssl on hosted server - host says there i sno security unless I buy separate certificate - is that right?

 
 
NotGiven
Guest
Posts: n/a
 
      12-19-2005
I successfully installed openssl on hosted server. The host company says
that offers no security or encryption unless I buy a certificate from them
or a third party like verisign.

If I try to open my site using httpS://, a prompt pops up telling me the
cert is not certified by anyone and do I want to accept it.

I accept it and there is a locked key in the browser.

Is the traffic encrypted (thus the tech is wrong)?

It is interesting in that the hosting company's login has the SAME prompt
when logging in.


 
Reply With Quote
 
 
 
 
Craig A. Finseth
Guest
Posts: n/a
 
      12-19-2005
In article <fWEpf.1844$(E-Mail Removed)>,
NotGiven <(E-Mail Removed)> wrote:
>I successfully installed openssl on hosted server. The host company says
>that offers no security or encryption unless I buy a certificate from them
>or a third party like verisign.


>If I try to open my site using httpS://, a prompt pops up telling me the
>cert is not certified by anyone and do I want to accept it.


>I accept it and there is a locked key in the browser.


>Is the traffic encrypted (thus the tech is wrong)?


Yes. Purchasing a certificate from an entity that has been pre-seeded
into your browser avoids the question, but, once accepted, the
encryption is identical.

Since some of the pre-seeded entities are happy to sell certificates
to anyone who applies for one, it is not clear that you're gaining any
real trust from them. Basically, you pays your $$$ to avoid the
question and possibly confused users.

Craig

 
Reply With Quote
 
 
 
 
Hairy One Kenobi
Guest
Posts: n/a
 
      12-19-2005
"NotGiven" <(E-Mail Removed)> wrote in message
news:fWEpf.1844$(E-Mail Removed)...
> I successfully installed openssl on hosted server. The host company says
> that offers no security or encryption unless I buy a certificate from them
> or a third party like verisign.
>
> If I try to open my site using httpS://, a prompt pops up telling me the
> cert is not certified by anyone and do I want to accept it.
>
> I accept it and there is a locked key in the browser.
>
> Is the traffic encrypted (thus the tech is wrong)?
>
> It is interesting in that the hosting company's login has the SAME prompt
> when logging in.


Hokay. Here's how it works (the quick version, I hasten to add!)

Basically, there are two types of certificate that allow either a client or
server to stake a claim as to who they are. The most common - and the one
you're interested in - is a server certificate.

There are a couple of basic checks that a browser can run (does it match the
URL? Is it out of date?), but, end of the day, it's the "clueless user" that
must decide (note quotes).

Of course, they wouldn't necessarily know a phishing site from a hole in the
ground, so what it took was someone to have a bright idea.

Like most things in (fairly modern) Computing, these certificates are
hierarchical - although they /can/ exist on their own, they don't /have/ to.

Rather than a "self signed" certificate (= "hand me a mirror; yep, that's
me"), you can beg or buy (but not necessarily borrow or steal) a
"sub-certificate" from someone else. If that someone else is big enough
(e.g. Verisign) and are willing to post a legal safeguard or two (I don't
think the concept of "this business will last about 40 seconds after the
first proven compromise" occurred to the lawyers), then they become a
"Trusted Third Party".

In other words, I might not trust /your/ site, but I trust the TTP to have
done at least a little bit of checking, and have at least some come-back,
should you disappear with my life savings.

Now, I see that you're using OE, and so are probably also using IE - go to
an SSL site (e.g. the login screen for your bank, or eBay), and double-click
the padlock. Take a look at the "Certification Path" tab - the TTP is the
one at the top. Firefox et al all have their own way of doing things, but
the information you get is (should be!) the same.

Hokay, so that's why most HTTPS (SSL) sites /don't/ pop up a window - there
are a list of TTPs (jargon alert: "TTP" is a simple concept that can be
understood by managers, so techies use the term "Certification Authorities",
or "CA"s) - it's only if your certificate isn't one of these that a warning
pops up.

In IE, it's so (ahem) rooted in the structure that "trust this certificate"
won't actually work in most cases - you have to go to the aforementioned
popup and trust the CA (or "root") certificate. It's called "root" because,
well, why only have two terms to describe exactly the same thing?

Any year now, one of our developers is going to realise this, and ditch the
whole self-signed CA thing when most of our products are installed. It'll
probably take a dark alley...

Anyway.

Now that we have a certificate, we need a way of guaranteeing that this is
passed unmolested betwixt server and client; this is where Nutscrape's SSL
comes in - a mechanism to securely allow the client to decide whether to
trust a certificate.

So, what encryption does that get us, in terms of securing what your user is
typing?

Well, none.

Na da.

Nothing whatsoever.

SSL is a mechanism that employs encryption to authenticate one or more sides
of the conversation. There's no data traffic involved whatsoever.

SSL == Encryption has always been an Urban Myth, and one that most techies
who know the difference just nod sagely and ignore - after all, in The Real
World, there's pretty much *always* a variety of encryption suites used.
"Pretty much" in this context means "this has put food on my table for
nearly seven years, and I've yet to see someone select the option. But it
*is* there, so some marked-for-evolutionary-deletion idiot probably /has/
configured it at some point"

So, to give you the short answer:

1. You can use a self-signed certificate, which must be in the format that
your hosting provider's web servers understand (let's face it, put two
techies in a room, ask them to work out a universal way of doing something,
and you'll get three incompatible standards)

2. This will popup a dialog box that - if you've got everything right - will
be only moderately terrifying in IE (one red warning, two green ticks) or
make you hide behind the sofa (Sun JRE)

3. If you buy a certificate from someone, then the user won't see a thing -
again, assuming that you've got everything right - but won't necessarily
achieve any more than not scaring the bejezus out of prospective customers.
Some companies use "proper" certificates for anything that a customer would
see, but use self-signing for things like WebMail.

4. Any encryption will be negotiated between the server and the client; best
practise dictates the strongest possible, but one side can always veto. Some
servers let you set a minimum level, but you're generally at the mercy of
your hosting provider.

HTH

--

Hairy One Kenobi

Disclaimer: the opinions expressed in this opinion do not necessarily
reflect the opinions of the highly-opinionated person expressing the opinion
in the first place. So there!


 
Reply With Quote
 
NotGiven
Guest
Posts: n/a
 
      12-20-2005
"Hairy One Kenobi" <abuse@[127.0.0.1]> wrote in message
newsVGpf.48609$(E-Mail Removed)...
> "NotGiven" <(E-Mail Removed)> wrote in message
> news:fWEpf.1844$(E-Mail Removed)...
>> I successfully installed openssl on hosted server. The host company says
>> that offers no security or encryption unless I buy a certificate from
>> them
>> or a third party like verisign.
>>
>> If I try to open my site using httpS://, a prompt pops up telling me the
>> cert is not certified by anyone and do I want to accept it.
>>
>> I accept it and there is a locked key in the browser.
>>
>> Is the traffic encrypted (thus the tech is wrong)?
>>
>> It is interesting in that the hosting company's login has the SAME prompt
>> when logging in.

>
> Hokay. Here's how it works (the quick version, I hasten to add!)
>
> Basically, there are two types of certificate that allow either a client
> or
> server to stake a claim as to who they are. The most common - and the one
> you're interested in - is a server certificate.
>
> There are a couple of basic checks that a browser can run (does it match
> the
> URL? Is it out of date?), but, end of the day, it's the "clueless user"
> that
> must decide (note quotes).
>
> Of course, they wouldn't necessarily know a phishing site from a hole in
> the
> ground, so what it took was someone to have a bright idea.
>
> Like most things in (fairly modern) Computing, these certificates are
> hierarchical - although they /can/ exist on their own, they don't /have/
> to.
>
> Rather than a "self signed" certificate (= "hand me a mirror; yep, that's
> me"), you can beg or buy (but not necessarily borrow or steal) a
> "sub-certificate" from someone else. If that someone else is big enough
> (e.g. Verisign) and are willing to post a legal safeguard or two (I don't
> think the concept of "this business will last about 40 seconds after the
> first proven compromise" occurred to the lawyers), then they become a
> "Trusted Third Party".
>
> In other words, I might not trust /your/ site, but I trust the TTP to have
> done at least a little bit of checking, and have at least some come-back,
> should you disappear with my life savings.
>
> Now, I see that you're using OE, and so are probably also using IE - go to
> an SSL site (e.g. the login screen for your bank, or eBay), and
> double-click
> the padlock. Take a look at the "Certification Path" tab - the TTP is the
> one at the top. Firefox et al all have their own way of doing things, but
> the information you get is (should be!) the same.
>
> Hokay, so that's why most HTTPS (SSL) sites /don't/ pop up a window -
> there
> are a list of TTPs (jargon alert: "TTP" is a simple concept that can be
> understood by managers, so techies use the term "Certification
> Authorities",
> or "CA"s) - it's only if your certificate isn't one of these that a
> warning
> pops up.
>
> In IE, it's so (ahem) rooted in the structure that "trust this
> certificate"
> won't actually work in most cases - you have to go to the aforementioned
> popup and trust the CA (or "root") certificate. It's called "root"
> because,
> well, why only have two terms to describe exactly the same thing?
>
> Any year now, one of our developers is going to realise this, and ditch
> the
> whole self-signed CA thing when most of our products are installed. It'll
> probably take a dark alley...
>
> Anyway.
>
> Now that we have a certificate, we need a way of guaranteeing that this is
> passed unmolested betwixt server and client; this is where Nutscrape's SSL
> comes in - a mechanism to securely allow the client to decide whether to
> trust a certificate.
>
> So, what encryption does that get us, in terms of securing what your user
> is
> typing?
>
> Well, none.
>
> Na da.
>
> Nothing whatsoever.
>
> SSL is a mechanism that employs encryption to authenticate one or more
> sides
> of the conversation. There's no data traffic involved whatsoever.
>
> SSL == Encryption has always been an Urban Myth, and one that most techies
> who know the difference just nod sagely and ignore - after all, in The
> Real
> World, there's pretty much *always* a variety of encryption suites used.
> "Pretty much" in this context means "this has put food on my table for
> nearly seven years, and I've yet to see someone select the option. But it
> *is* there, so some marked-for-evolutionary-deletion idiot probably /has/
> configured it at some point"
>
> So, to give you the short answer:
>
> 1. You can use a self-signed certificate, which must be in the format that
> your hosting provider's web servers understand (let's face it, put two
> techies in a room, ask them to work out a universal way of doing
> something,
> and you'll get three incompatible standards)
>
> 2. This will popup a dialog box that - if you've got everything right -
> will
> be only moderately terrifying in IE (one red warning, two green ticks) or
> make you hide behind the sofa (Sun JRE)
>
> 3. If you buy a certificate from someone, then the user won't see a
> thing -
> again, assuming that you've got everything right - but won't necessarily
> achieve any more than not scaring the bejezus out of prospective
> customers.
> Some companies use "proper" certificates for anything that a customer
> would
> see, but use self-signing for things like WebMail.
>
> 4. Any encryption will be negotiated between the server and the client;
> best
> practise dictates the strongest possible, but one side can always veto.
> Some
> servers let you set a minimum level, but you're generally at the mercy of
> your hosting provider.
>
> HTH
>
> --
>
> Hairy One Kenobi
>
> Disclaimer: the opinions expressed in this opinion do not necessarily
> reflect the opinions of the highly-opinionated person expressing the
> opinion
> in the first place. So there!


Wow - thanks for the explanation - many thanks


 
Reply With Quote
 
me@someplace.else
Guest
Posts: n/a
 
      12-21-2005

Craig,

You appear to be reasonably familiar with SSL and the concepts behind
browser/server communications, judging from the fact you have
generated your own certificate and installed it on your server. The
bottom line is that the communications exchanged between your server
and a visitor's browser through an HTTPS session, will be just as
secure using your self-signed certificate as they would be using a
certificate purchased from Verisign or Comodo or any other vendor -
provided the private key of the key-pair you generated is at least
1024-bits. However, this is purely the technological component of the
security/trust issue.

Just because a communications session between a browser and a server
is encrypted (SSL-secured), doesn't mean "trust" is automatically
guaranteed. This is where a so-called "trusted third party" comes
into the equation. In the real/physical world, a passport is a form
of "trusted" identification, because the identity of the person who
has been issued the passport is "vouched for" by the government during
the process involved in acquiring the passport. In this case, the
government operates in a role of "trusted authority" (whether one
trusts or doesn't trust the government in general is irrelevant for
the purposes of this example, the government is recognized as being an
authority that can vouch for the passport holder's identity). In the
online world, the pseudo-equivalent "trusted authority", is a CA - a
Certification Authority - as in, someone such as Verisign, Comodo,
Thawte, etc. Here's where the authority comparison doesn't hold the
same weight compared to physical identification such as a passport or
driver's license. Why? Because, *who* decided these companies should
be "trusted authorities"? Just because Microsoft (or other browser
producer) happens to bundle the root certificates of these vendors in
with their browser software, is not a convincing reason to assume they
should be considered "trusted authorities". But over the past number
of years, these companies have done a terrific job of marketing their
business interests and have become quite firmly entrenched - in the
minds of consumers - as exactly that - trusted "authorities".

Therefore, the certificates "signed" by these companies have acquired
a substantive level of "trust" simply because they have been issued by
these well-known certificate vendors. And to give credit where it's
due, in a lot of cases these vendors actually do spend some time and
effort to check the information provided by a certificate applicant,
and some amount of due diligence in verifying that the person/company
that has applied, really *is* who they say they are. But, that's not
the same thing as saying that the person who's been issued a
certificate by one of these vendors is actually an honest business, or
a dishonest one - and all of the certificate vendors flatly disclaim
any responsibility or liability for anything beyond simple identity
verification (and even that has disclaimers attached). The
certificate's purpose is only to "validate" the (supposed) identity of
the certificate holder. But even that is not always the case -- most
of the big vendors offer "digital certificates in minutes", and some
(Go-Daddy comes to mind) even state on their website that there is no
documentation required and no telephone verification done. The
certificate is issued the moment the payment transaction has cleared.

As a consumer, you have no way of knowing if the certificate that was
issued to xyz-widgetware website is one of these instant, "we check
nothing" types, or a certificate that was issued after the CA actually
spent some time reviewing copies of incorporation papers, bank
statements, Dunn & Bradstreet references, and so forth. The only thing
the consumer sees (or doesn't see) is: the self-issued certificate
will cause the browser to raise a security popup (once the user
accepts the certificate, they won't get the warning again), whereas a
certificate issued by a known vendor will not popup any message box.
Therefore, the real security question is: how much trust does one have
in conducting business with an e-commerce website that is using a
commercial certificate compared to a self-issued certificate? As
technology professionals we might be able to understand these issues,
but does the average consumer? We probably all know the answer to
that - *most* consumers are click-happy - they view popups as mostly
an annoyance, and thus quickly dispose of them with barely even a
glance at the message.

However, having said that, things are going to get more difficult for
those end-users, and this in turn will make this issue far more
important to anyone who uses (or doesn't use) digital certificates in
some form or another. Those who have been following the recent
Microsoft product information announcements regarding the upcoming
release of IE7 and Windows Vista, will be aware that there are going
to be impacts to SSL-enabled websites, and likely significant barriers
to unsigned code downloads (for those developers in this group who
offer those types of deliverables). The objective is of course to
tighten security for end users in the interest of protecting them from
malicious software. According to Microsoft's announcements, users are
going to see a rise in the frequency of browser warning messages, and
the number of 'hoops' they must jump through in order to connect to a
site which is using 'questionable' certificates, and for existing
certificates which may be being inappropriately used, or which are
associated with applications or websites that implement SSL formats
that are no longer going to be supported by IE7. There may be other
problems that IE7 introduces for existing certificates, which have not
yet been identified based on the details Microsoft have released so
far. The information for software developers who do not digitally
sign their distributables, is that this is going to become more and
more of a problem also.

Is a self-signed certificate going to present a problem when judged
against a commercial certificate? Until IE7 (and future technology
like Vista) hits the market, it's anyone's guess. But whether it does
or doesn't create a 'technology' problem, the real question is what is
it worth to the bottom line? At $200 or $400, it could well be worth
the time to learn how to generate one's own certificate; at $20 or
$50, perhaps not.

- Brian



On Mon, 19 Dec 2005 22:06:28 -0000, Craig A. Finseth
<(E-Mail Removed)> wrote:

>In article <fWEpf.1844$(E-Mail Removed)>,
>NotGiven <(E-Mail Removed)> wrote:
>>I successfully installed openssl on hosted server. The host company says
>>that offers no security or encryption unless I buy a certificate from them
>>or a third party like verisign.

>
>>If I try to open my site using httpS://, a prompt pops up telling me the
>>cert is not certified by anyone and do I want to accept it.

>
>>I accept it and there is a locked key in the browser.

>
>>Is the traffic encrypted (thus the tech is wrong)?

>
>Yes. Purchasing a certificate from an entity that has been pre-seeded
>into your browser avoids the question, but, once accepted, the
>encryption is identical.
>
>Since some of the pre-seeded entities are happy to sell certificates
>to anyone who applies for one, it is not clear that you're gaining any
>real trust from them. Basically, you pays your $$$ to avoid the
>question and possibly confused users.
>
>Craig


 
Reply With Quote
 
nemo_outis
Guest
Posts: n/a
 
      12-21-2005
http://www.velocityreviews.com/forums/(E-Mail Removed) wrote in
news(E-Mail Removed):

>
> Craig,
>
> You appear to be reasonably familiar with SSL and the concepts behind
> browser/server communications, judging from the fact you have
> generated your own certificate and installed it on your server. The
> bottom line is that the communications exchanged between your server
> and a visitor's browser through an HTTPS session, will be just as
> secure using your self-signed certificate as they would be using a
> certificate purchased from Verisign or Comodo or any other vendor -
> provided the private key of the key-pair you generated is at least
> 1024-bits. However, this is purely the technological component of the
> security/trust issue.
>
> Just because a communications session between a browser and a server
> is encrypted (SSL-secured), doesn't mean "trust" is automatically
> guaranteed. This is where a so-called "trusted third party" comes
> into the equation. In the real/physical world, a passport is a form
> of "trusted" identification, because the identity of the person who
> has been issued the passport is "vouched for" by the government during
> the process involved in acquiring the passport. In this case, the
> government operates in a role of "trusted authority" (whether one
> trusts or doesn't trust the government in general is irrelevant for
> the purposes of this example, the government is recognized as being an
> authority that can vouch for the passport holder's identity). In the
> online world, the pseudo-equivalent "trusted authority", is a CA - a
> Certification Authority - as in, someone such as Verisign, Comodo,
> Thawte, etc. Here's where the authority comparison doesn't hold the
> same weight compared to physical identification such as a passport or
> driver's license. Why? Because, *who* decided these companies should
> be "trusted authorities"? Just because Microsoft (or other browser
> producer) happens to bundle the root certificates of these vendors in
> with their browser software, is not a convincing reason to assume they
> should be considered "trusted authorities". But over the past number
> of years, these companies have done a terrific job of marketing their
> business interests and have become quite firmly entrenched - in the
> minds of consumers - as exactly that - trusted "authorities".
>
> Therefore, the certificates "signed" by these companies have acquired
> a substantive level of "trust" simply because they have been issued by
> these well-known certificate vendors. And to give credit where it's
> due, in a lot of cases these vendors actually do spend some time and
> effort to check the information provided by a certificate applicant,
> and some amount of due diligence in verifying that the person/company
> that has applied, really *is* who they say they are. But, that's not
> the same thing as saying that the person who's been issued a
> certificate by one of these vendors is actually an honest business, or
> a dishonest one - and all of the certificate vendors flatly disclaim
> any responsibility or liability for anything beyond simple identity
> verification (and even that has disclaimers attached). The
> certificate's purpose is only to "validate" the (supposed) identity of
> the certificate holder. But even that is not always the case -- most
> of the big vendors offer "digital certificates in minutes", and some
> (Go-Daddy comes to mind) even state on their website that there is no
> documentation required and no telephone verification done. The
> certificate is issued the moment the payment transaction has cleared.
>
> As a consumer, you have no way of knowing if the certificate that was
> issued to xyz-widgetware website is one of these instant, "we check
> nothing" types, or a certificate that was issued after the CA actually
> spent some time reviewing copies of incorporation papers, bank
> statements, Dunn & Bradstreet references, and so forth. The only thing
> the consumer sees (or doesn't see) is: the self-issued certificate
> will cause the browser to raise a security popup (once the user
> accepts the certificate, they won't get the warning again), whereas a
> certificate issued by a known vendor will not popup any message box.
> Therefore, the real security question is: how much trust does one have
> in conducting business with an e-commerce website that is using a
> commercial certificate compared to a self-issued certificate? As
> technology professionals we might be able to understand these issues,
> but does the average consumer? We probably all know the answer to
> that - *most* consumers are click-happy - they view popups as mostly
> an annoyance, and thus quickly dispose of them with barely even a
> glance at the message.
>
> However, having said that, things are going to get more difficult for
> those end-users, and this in turn will make this issue far more
> important to anyone who uses (or doesn't use) digital certificates in
> some form or another. Those who have been following the recent
> Microsoft product information announcements regarding the upcoming
> release of IE7 and Windows Vista, will be aware that there are going
> to be impacts to SSL-enabled websites, and likely significant barriers
> to unsigned code downloads (for those developers in this group who
> offer those types of deliverables). The objective is of course to
> tighten security for end users in the interest of protecting them from
> malicious software. According to Microsoft's announcements, users are
> going to see a rise in the frequency of browser warning messages, and
> the number of 'hoops' they must jump through in order to connect to a
> site which is using 'questionable' certificates, and for existing
> certificates which may be being inappropriately used, or which are
> associated with applications or websites that implement SSL formats
> that are no longer going to be supported by IE7. There may be other
> problems that IE7 introduces for existing certificates, which have not
> yet been identified based on the details Microsoft have released so
> far. The information for software developers who do not digitally
> sign their distributables, is that this is going to become more and
> more of a problem also.
>
> Is a self-signed certificate going to present a problem when judged
> against a commercial certificate? Until IE7 (and future technology
> like Vista) hits the market, it's anyone's guess. But whether it does
> or doesn't create a 'technology' problem, the real question is what is
> it worth to the bottom line? At $200 or $400, it could well be worth
> the time to learn how to generate one's own certificate; at $20 or
> $50, perhaps not.
>
> - Brian



A thoughtful and balanced post.

Regards,

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
problem in running a basic code in python 3.3.0 that includes HTML file Satabdi Mukherjee Python 1 04-04-2013 07:48 PM
I Successfully Installed Windows XP X64 Edition on my Brand New DELL XPS 600. Kevin John Panzke Windows 64bit 1 05-17-2006 03:08 PM
Unless unless Gábor SEBESTYÉN Ruby 3 06-17-2005 08:54 AM
MozPython: Why my MozPython did not work after installed successfully? Phipps Xue Python 0 01-09-2004 09:17 AM
app not working unless vb.net installed on server keith ASP .Net Web Services 1 07-22-2003 03:16 PM



Advertisments