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
Bill W. 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
On 3/2/07, Bill W. [email protected] 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 C.
http://depixelate.com
Hi Zack,
Zack C. 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
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…
I’m sure other providers have them as well, not endorsing rapidssl
necessarily.
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 H. 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
Hi Anton,
Anton A. wrote:
Bill W. 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
Anton A. 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.
Ehm, wildcard SSL certificates are valid for a specific domain and all
sub-domains of that domain.
So, for instance, I can secure…
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.
Anton A. 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.
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 G. said the following on 03/03/2007 02:52 PM:
On Mar 2, 1:38 pm, Anton A. [email protected] 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)
Andreas S. said the following on 03/03/2007 06:06 PM:
Anton A. 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
Anton A. wrote:
Andreas S. said the following on 03/03/2007 06:06 PM:
Anton A. 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.
Andreas S. 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
Anton A. 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?
Anton A. wrote:
Andreas S. 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.
Andreas S. 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.
Andreas S. 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
Anton A. wrote:
Andreas S. 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 forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs