Forum: Ruby on Rails SSL cert - mydomain.com? or www.mydomain.com?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
2b891e820c238ded365d035771603f21?d=identicon&s=25 Bill Walton (Guest)
on 2007-03-02 06:16
(Received via mailing list)
I'm getting my first SSL cert and have to specify whether the cert is
for https://mydomain.com or https://www.mydomain.com.  I'm guessing
there's a signifant difference buried in that choice somewhere, but have
no idea what it is.  I'd sure like to avoid "painting myself into a
corner."  Can someone point me to something that would help me
understand the implications of the choice I make?

Thanks,
Bill
140c065a9604b5321768cbe02e91ef30?d=identicon&s=25 Anton Aylward (Guest)
on 2007-03-02 10:17
(Received via mailing list)
Bill Walton said the following on 03/02/2007 12:16 AM:
> I'm getting my first SSL cert and have to specify whether the cert is
> for https://mydomain.com or https://www.mydomain.com.  I'm guessing
> there's a signifant difference buried in that choice somewhere, but have
> no idea what it is.  I'd sure like to avoid "painting myself into a
> corner."  Can someone point me to something that would help me
> understand the implications of the choice I make?

You are correct to be concerned.
The lack of ability of X.509 to deal with 'aliases' and to interpret DNS
and
other directory information is a known shortcoming and problem.

Most hosting services off the ability to alias the two URL forms - this
is
easy with DNS.   From an end users point of view they are the same.
Browsers will convert "mydomain" into "mydomain.com" and
"www.myomain.com"
transparently for the user even if DNS does not do the aliasing.  But
the
roots of X.509 are tied up with the ISO-RM which was rather antagonistic
to
the IETF IP model.  Its addressing structure was "prescriptive" and if
not
actually authoritarian then highly paternalistic (aka 'we know what's
good
for you and you should do it this way!'), so this user convenience did
not
exist.

You could, of course, bind to an IP address, but that limits you in
other
ways :-(

So you are left with two solutions.

   a) but a cert for each "domain" and don't do DNS aliasing
        but have, in effect, two sites that use the same database

   b) pick one as the 'real one and set up the DNS for the other
        to point to a page that redirects to the real one


While about it, write to the IETF and tell them that you're annoyed that
X.509 doesn't support aliasing and throw your support behind the groups
that
are working to address this matter in future releases.

--
Man does not live by words alone, despite the fact that sometimes he has
to
eat them.
    Adlai E. Stevenson Jr., quoted by Human Behavior, May 1978
2b891e820c238ded365d035771603f21?d=identicon&s=25 Bill Walton (Guest)
on 2007-03-02 14:50
(Received via mailing list)
Hi Anton,

Anton Aylward wrote:

> Bill Walton said the following on 03/02/2007 12:16 AM:
>> I'm getting my first SSL cert and have to specify whether the cert is
>> for https://mydomain.com or https://www.mydomain.com.

> You are correct to be concerned.
> The lack of ability of X.509 to deal with 'aliases' and to interpret
> DNS and other directory information is a known shortcoming
> and problem.

Sorry to be so dense.  Like I said... first-timer.  I may be missing
other
stuff too, but after thinking about it, my primary concern at this point
is
about my desire to put parts of my app under SSL and to leave other
parts
unsecured.

For example:
www.mydomain.com  - unsecured
www.mydomain.com/create  - all methods in the create controller under
SSL

My understanding was that I could just put a before_filter on the
controllers I want to have secured so that any request to, for example,
http://www.mydomain.com/create/  would actually go to
https://www.mydomain.com/create.

Is that right?  And if so, is one of the choices I'm being given (this
is on
a hosted VPS account with private IP) going to handle this better than
the
other?

Thanks very much for your help.

Best regards,
Bill
C4dc94c893471878a105761a9207f29b?d=identicon&s=25 Zack Chandler (Guest)
on 2007-03-02 16:43
(Received via mailing list)
On 3/2/07, Bill Walton <bill.walton@charter.net> wrote:
> My understanding was that I could just put a before_filter on the
> controllers I want to have secured so that any request to, for example,
> http://www.mydomain.com/create/  would actually go to
> https://www.mydomain.com/create.
>
> Is that right?  And if so, is one of the choices I'm being given (this is on
> a hosted VPS account with private IP) going to handle this better than the
> other?
>

Use the ssl_requirements plugin for this.  You can specify which
actions should be run through https.

As far as the ssl cert, you can always buy a wildcard cert if you want
all options open.  Otherwise buy www.mydomain.com and save some money.

Hope this helps.

--
Zack Chandler
http://depixelate.com
2b891e820c238ded365d035771603f21?d=identicon&s=25 Bill Walton (Guest)
on 2007-03-02 17:03
(Received via mailing list)
Hi Zack,

Zack Chandler wrote:

>> My understanding was that I could just put a before_filter on the
>> controllers I want to have secured so that any request to, for example,
>> http://www.mydomain.com/create/  would actually go to
>> https://www.mydomain.com/create.
>>
>
> Use the ssl_requirements plugin for this.  You can specify which
> actions should be run through https.
 >
> As far as the ssl cert, you can always buy a wildcard cert if you
> want all options open.  Otherwise buy www.mydomain.com and
> save some money.
>
> Hope this helps.

Thanks, Zack.  That was exactly the info and advice I was hoping for.

Best regards,
Bill
2f9a03aa0fcfe945229cb6126eda2cb2?d=identicon&s=25 Philip Hallstrom (Guest)
on 2007-03-02 17:09
(Received via mailing list)
> I'm getting my first SSL cert and have to specify whether the cert is
> for https://mydomain.com or https://www.mydomain.com.  I'm guessing
> there's a signifant difference buried in that choice somewhere, but have
> no idea what it is.  I'd sure like to avoid "painting myself into a
> corner."  Can someone point me to something that would help me
> understand the implications of the choice I make?

You could also get a wildcard certificate...

http://www.rapidssl.com/ssl-certificate-products/r...

I'm sure other providers have them as well, not endorsing rapidssl
necessarily.
140c065a9604b5321768cbe02e91ef30?d=identicon&s=25 Anton Aylward (Guest)
on 2007-03-02 20:44
(Received via mailing list)
Using a wild-card certificate means that there is no means to identify
the
host you are connecting to is the host you intend to connect to.

Speaking as someone who makes his living in the security world I would
say
that this invalidates so much about what TLS/SSL was designed to do.

Would I trust a site that uses one?  No.

Philip Hallstrom said the following on 03/02/2007 11:19 AM:
>
> I'm sure other providers have them as well, not endorsing rapidssl
> necessarily.

--
Many of the characters are fools and they are always playing
tricks on me and treating me badly.
   -- Jorge Luis Borges, from "Writers on Writing" by Jon Winokur
3a83969376c805ef5b6042191fdb0ff3?d=identicon&s=25 Andreas S. (andreas)
on 2007-03-02 21:00
Anton Aylward wrote:
> Using a wild-card certificate means that there is no means to identify
> the
> host you are connecting to is the host you intend to connect to.
>
> Speaking as someone who makes his living in the security world I would
> say
> that this invalidates so much about what TLS/SSL was designed to do.
>
> Would I trust a site that uses one?  No.

The wildcard only works for SUBdomains of a specific domain.
6856e946eaec76892a99123ebf64c684?d=identicon&s=25 Chris Grant (Guest)
on 2007-03-03 20:53
(Received via mailing list)
Ehm, wildcard SSL certificates are valid for a specific domain and all
sub-domains of that domain.

So, for instance, I can secure...

mydomain.com
www.mydomain.com
store.mydomain.com
webmail.mydomain.com
etc...

... using one wildcard SSL certificate.  The padlock still shows up
and it's a secure solution -- no doubt about it.

They are a little more expensive but I think they definitely have
their place on a site that partitions functionality under certain sub-
domains (see: logical).

Correct me if I'm wrong because I've been shopping wildcard SSL's for
the past couple days and am likely to purchase one soon.
140c065a9604b5321768cbe02e91ef30?d=identicon&s=25 Anton Aylward (Guest)
on 2007-03-03 23:57
(Received via mailing list)
Indeed, you can secure all  the subdomains with a wild card certificate,
but
you can't be certain which host in the domain you are connecting to

         ChristianBooksForSale.mydomain.com
   YourFavouritePorn.mydomain.com

This may not matter to you but it will matter to th customer.
Heck, it may matter to you if the customer gets upset about it or

The padlock showing up only says that a SSL connection been established.
You could do the same thing with a self-signed certificate.

From the vulnerability POV you have a common failure mod; an attacker
only
needs to subvert on certificate and he has the whole domain. This means
you
have a 'weakest link in the chain situation'.

Suppose you put the same certificate on a "test server" and on your main
production server. The security from the SSL server authentication for
your
main server will depend on the security on your test server.

You've in effect multiplied your risk.

The history of attacks is that the attackers don't try for the
(established)
connection.  Its much easier to subvert the machine in any number of
ways.
My newsfeeds tell me of more and more each week.

If cost is an issue, you may wish to investigate Reverse Proxying with a
single external certificate and multiple internal certificates (either
self-signed or issued from an internal CA).



Chris Grant said the following on 03/03/2007 02:52 PM:
>
> On Mar 2, 1:38 pm, Anton Aylward <a...@si.on.ca> wrote:
>>>> I'm getting my first SSL cert and have to specify whether the cert is
>> Many of the characters are fools and they are always playing
>> tricks on me and treating me badly.
>>    -- Jorge Luis Borges, from "Writers on Writing" by Jon Winokur
>
>
>
--
I'm always interested when [cold callers] try to flog conservatories.
Anyone who can actually attach a conservatory to a fourth floor flat
stands a marginally better than average chance of winning my custom.
(Seen on Usenet)
3a83969376c805ef5b6042191fdb0ff3?d=identicon&s=25 Andreas S. (andreas)
on 2007-03-04 00:06
Anton Aylward wrote:
> Suppose you put the same certificate on a "test server" and on your main
> production server. The security from the SSL server authentication for
> your
> main server will depend on the security on your test server.

So you would buy a certificate for a test server? That doesn't make any
sense.
140c065a9604b5321768cbe02e91ef30?d=identicon&s=25 Anton Aylward (Guest)
on 2007-03-04 00:43
(Received via mailing list)
Andreas Schwarz said the following on 03/03/2007 06:06 PM:
> Anton Aylward wrote:
>> Suppose you put the same certificate on a "test server" and on your main
>> production server. The security from the SSL server authentication for
>> your
>> main server will depend on the security on your test server.
>
> So you would buy a certificate for a test server? That doesn't make any
> sense.
>

Right.  but when you buy a wildcard cert that's what you've done.
You've
bought a cert for EVERY machine in your domain.

Including the ones you haven't secured.

-
A program designed for inputs from people is usually stressed beyond
breaking point by computer-generated inputs. -- Dennis Ritchie
3a83969376c805ef5b6042191fdb0ff3?d=identicon&s=25 Andreas S. (andreas)
on 2007-03-04 13:38
Anton Aylward wrote:
> Andreas Schwarz said the following on 03/03/2007 06:06 PM:
>> Anton Aylward wrote:
>>> Suppose you put the same certificate on a "test server" and on your main
>>> production server. The security from the SSL server authentication for
>>> your
>>> main server will depend on the security on your test server.
>>
>> So you would buy a certificate for a test server? That doesn't make any
>> sense.
>>
>
> Right.  but when you buy a wildcard cert that's what you've done.
> You've
> bought a cert for EVERY machine in your domain.
>
> Including the ones you haven't secured.

It doesn't make any sense to use the key on a test server - a
self-signed key is sufficient for testing - so even if an attacker
manages to break into the test server, he still needs to break into the
main server to steal the key. You are right that in theory it increases
the risk a little bit, because the attacker has to use the main server
only for stealing the key, not to set up his evil application, but the
whole thing is still a rather far-fetched scenario. There is always a
tradeoff between security and cost/effort, and I think using a wildcard
certificate is a good tradeoff.
140c065a9604b5321768cbe02e91ef30?d=identicon&s=25 Anton Aylward (Guest)
on 2007-03-04 14:14
(Received via mailing list)
Andreas Schwarz said the following on 03/04/2007 07:38 AM:
>
> It doesn't make any sense to use the key on a test server - a
> self-signed key is sufficient for testing - so even if an attacker
> manages to break into the test server, he still needs to break into the
> main server to steal the key.

True, bit you're missing the point.  The wildcard covers your whole
domain.

Once on the test server an attacker can use that as a platform to gain
more
information and launch other attack.  He's "inside" the 'ring of
protection'
now. His view of what's valuable and your view may differ.  He may not
be
out to steal your cert, he might want to use your platform to run some
'bot
to carry out a DDoS on another site, act as a site for some phishing
expedition, store warez, store child pornography for a ring, act as a
store/server of material that is violating copyright such as movies or
songs.   Who knows.  Whatever: its your loss, your cost - perhaps legal
cost
 proving you weren't culpable.  Maybe the DMCA police cart off your
machine
& software and you have to institute legal action to get it back.

All this has happened out there in the real world.


> You are right that in theory it increases
> the risk a little bit, because the attacker has to use the main server
> only for stealing the key, not to set up his evil application, but the
> whole thing is still a rather far-fetched scenario.

All attack models seem far fetched to the site owners, I've found, until
the
hackers come along and demonstrate more creativity and ingenuity than we
expected.  That has been the consistent history of network and host
security.  "I didn't think they could do that" - but they did!

The point isn't that about what you think possible but that that you've
opened up a whole new set of avenues without instituting specific
controls
to address them.

> There is always a
> tradeoff between security and cost/effort, and I think using a wildcard
> certificate is a good tradeoff.

Your decision.
It seems far removed from your original issue.


--
  Intruder Alert
  Black channels of unknown song
  Whisper through your walls
3a83969376c805ef5b6042191fdb0ff3?d=identicon&s=25 Andreas S. (andreas)
on 2007-03-04 14:19
Anton Aylward wrote:
> True, bit you're missing the point.  The wildcard covers your whole
> domain.
>
> Once on the test server an attacker can use that as a platform to gain  more
> information and launch other attack.  He's "inside" the 'ring of  protection'
> now. His view of what's valuable and your view may differ.  He may not be
> out to steal your cert, he might want to use your platform to run some 'bot
> to carry out a DDoS on another site, act as a site for some phishing
> expedition, store warez, store child p0rnography for a ring, act as a
> store/server of material that is violating copyright such as movies or
> songs.   Who knows.  Whatever: its your loss, your cost - perhaps legal
> cost proving you weren't culpable.

Er... and what's this all got to do with the certificate?
140c065a9604b5321768cbe02e91ef30?d=identicon&s=25 Anton Aylward (Guest)
on 2007-03-04 22:16
(Received via mailing list)
Andreas Schwarz said the following on 03/04/2007 08:19 AM:
>> store/server of material that is violating copyright such as movies or
>> songs.   Who knows.  Whatever: its your loss, your cost - perhaps legal
>> cost proving you weren't culpable.
>
> Er... and what's this all got to do with the certificate?

Do you think that in order to get the information or subvert the
protection
offered by the certificate an attacker will do a head's on attack on the
cert?  No Way!  Most attacks and subversion are step-by-step going for
back
door or weaknesses elsewhere and using them as a springboard.

All the certificate does is encrypt traffic.  It doesn't protect your
site.
In particular it doesn't protect your site from any problem that might
plague a web service or a server or a machine connected to the Internet.

If you do have traffic or transactions that you want to protect you'll
need
more than a certificate!  What you'll need will depend on many factors;
how
you've coded, specifics of your network ... Wildcard certs are like
wildcards in DNS, they can produce some unexpected side effects.
Incidentally, do you have complete _and_ _sole_ control of your DNS?



--
"Objectives are not fate; they are direction. They are not commands;
they
are commitments. They do not determine the future; they are a means to
mobilize resources and energies of the business for the making of the
future."
   -- Peter F. Drucker.
3a83969376c805ef5b6042191fdb0ff3?d=identicon&s=25 Andreas S. (andreas)
on 2007-03-05 02:18
Anton Aylward wrote:
> Andreas Schwarz said the following on 03/04/2007 08:19 AM:
>>> store/server of material that is violating copyright such as movies or
>>> songs.   Who knows.  Whatever: its your loss, your cost - perhaps legal
>>> cost proving you weren't culpable.
>>
>> Er... and what's this all got to do with the certificate?
>
> Do you think that in order to get the information or subvert the
> protection
> offered by the certificate an attacker will do a head's on attack on the
> cert?  No Way!  Most attacks and subversion are step-by-step going for
> back
> door or weaknesses elsewhere and using them as a springboard.

Again: what has this all got to do with the wildcard certificate? If
someone gains control over an unsecured "test server", it doesn't matter
if you have a wildcard certificates that includes the domain of the test
server or not. Without the secret key the attacker can't do anything. If
the attacker CAN get the secret key from the main server, he most likely
could also modify websites directly or do all kinds of other stuff. So
in most cases the security advantage of a seperate certificate for each
subdomain is really irrelevant.
140c065a9604b5321768cbe02e91ef30?d=identicon&s=25 Anton Aylward (Guest)
on 2007-03-05 02:40
(Received via mailing list)
Andreas Schwarz said the following on 03/04/2007 08:18 PM:
>
> server or not. Without the secret key the attacker can't do anything.

Not so.
If the attacked can subvert any machine in the domain he can do things
that
neither of us can guess a and are limited only by his skill.

It has nothing whatsoever to do with getting the key.

> So
> in most cases the security advantage of a seperate certificate for each
> subdomain is really irrelevant.

Only if you apply the same security policy to all - which you are doing
explicitly with the 'shared' cert.

This gets back to much earlier in the discussion, before the wildcard
'shared' cert came up.

What are you trying to protect?   The SSL link - which is all the cert
allows you to protect - is a transient thing.  There is a long history
of
"SSL Enabled" sites being subverted and the information that goes over
the
link obtained without cracking the crypto.

As I said, attackers rarely attack head on.


--
Like all weak men he laid an exaggerated stress on not changing one's
mind.
    W. Somerset Maugham, "Of Human Bondage", 1915
3a83969376c805ef5b6042191fdb0ff3?d=identicon&s=25 Andreas S. (andreas)
on 2007-03-05 02:46
Anton Aylward wrote:
> Andreas Schwarz said the following on 03/04/2007 08:18 PM:
>>
>> server or not. Without the secret key the attacker can't do anything.
>
> Not so.
> If the attacked can subvert any machine in the domain he can do things
> that
> neither of us can guess a and are limited only by his skill.
>
> It has nothing whatsoever to do with getting the key.

For the third time: what does this all have to do with wildcard
certificates? You said you wouldn't trust a site with a wildcard cert.
Why? The only difference between a wildcard cert and a normal cert is
granularity.
This topic is locked and can not be replied to.