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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On 3/2/07, Bill Walton <bill.walton-xwVYE8SWAR3R7s880joybQ@public.gmane.org> wrote:> > 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? >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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
> 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/rapidssl/usd/wildcard-ssl-certificate.htm I''m sure other providers have them as well, not endorsing rapidssl necessarily. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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 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/rapidssl/usd/wildcard-ssl-certificate.htm > > 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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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. -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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. On Mar 2, 1:38 pm, Anton Aylward <a...-XdPx9462FWc@public.gmane.org> 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. > > Philip Hallstrom said the following on 03/02/2007 11:19 AM: > > >> I''m getting my first SSL cert and have to specify whether the cert is > >> forhttps://mydomain.comorhttps://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/rapidssl/usd/wildcar... > > > 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--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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:> 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.
>
> On Mar 2, 1:38 pm, Anton Aylward <a...-XdPx9462FWc@public.gmane.org>
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.
>>
>> Philip Hallstrom said the following on 03/02/2007 11:19 AM:
>>
>>>> I''m getting my first SSL cert and have to specify
whether the cert is
>>>> forhttps://mydomain.comorhttps://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/rapidssl/usd/wildcar...
>>> 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
>
>
>
--
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)
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---
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. -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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. -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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? -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Andreas Schwarz said the following on 03/04/2007 08:19 AM:> 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?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. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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. -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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. -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---