successfully installed openssl on hosted server - host says there i sno security unless I buy separa

Discussion in 'Computer Security' started by NotGiven, Dec 19, 2005.

  1. NotGiven

    NotGiven Guest

    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.
     
    NotGiven, Dec 19, 2005
    #1
    1. Advertising

  2. In article <fWEpf.1844$>,
    NotGiven <> 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
     
    Craig A. Finseth, Dec 19, 2005
    #2
    1. Advertising

  3. "NotGiven" <> wrote in message
    news:fWEpf.1844$...
    > 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!
     
    Hairy One Kenobi, Dec 19, 2005
    #3
  4. NotGiven

    NotGiven Guest

    "Hairy One Kenobi" <abuse@[127.0.0.1]> wrote in message
    news:pVGpf.48609$...
    > "NotGiven" <> wrote in message
    > news:fWEpf.1844$...
    >> 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
     
    NotGiven, Dec 20, 2005
    #4
  5. NotGiven

    Guest

    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
    <> wrote:

    >In article <fWEpf.1844$>,
    >NotGiven <> 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
     
    , Dec 21, 2005
    #5
  6. NotGiven

    nemo_outis Guest

    wrote in
    news:p:

    >
    > 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,
     
    nemo_outis, Dec 21, 2005
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Wil
    Replies:
    3
    Views:
    4,623
    SecPer
    Nov 18, 2008
  2. Doug Fox

    OpenSSL in Windows Server 2003?

    Doug Fox, Oct 17, 2005, in forum: Computer Security
    Replies:
    0
    Views:
    792
    Doug Fox
    Oct 17, 2005
  3. Notgiven
    Replies:
    2
    Views:
    691
    Colin McKinnon
    Aug 2, 2006
  4. Kevin John Panzke
    Replies:
    1
    Views:
    493
    Jean-Baptiste Faure
    May 17, 2006
  5. viza
    Replies:
    17
    Views:
    1,248
    Kyle T. Jones
    Jun 24, 2008
Loading...

Share This Page