Greetings! Please forgive the cross post. This is my first experience with implementing SSL, so I''m not even sure if this is an application development or deployment issue. I hope you''ll forgive the "stupid newbie" questions. I''m going to install SSL over part of my app and will be using a cert from Geotrust. I''m considering two options: Quick SSL, and Quick SSL Premium ( http://www.geotrust.com/buy/certificate_compare.asp ). The main difference is that QuickSSL has a static seal and the Premium has a "Dynamic seal stating transaction is secure. Displays real-time date / timestamp" 1) Does the seal go on all the secure pages? 2) Does the Dynamic seal pose any issues for Rails apps? I''d really appreciate hearing from anyone with experience with this stuff. Thanks, Bill --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Deploying Rails" group. To post to this group, send email to rubyonrails-deployment-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-deployment-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-deployment?hl=en -~----------~----~----~----~------~----~------~--~---
Bill Walton said the following on 02/28/2007 01:36 PM:> > I''m going to install SSL over part of my app and will be using a cert > from Geotrust. I''m considering two options: Quick SSL, and Quick SSL > Premium ( http://www.geotrust.com/buy/certificate_compare.asp ). The > main difference is that QuickSSL has a static seal and the Premium has a > "Dynamic seal stating transaction is secure. Displays real-time date / > timestamp" > > 1) Does the seal go on all the secure pages? > 2) Does the Dynamic seal pose any issues for Rails apps? > > I''d really appreciate hearing from anyone with experience with this stuff.Basically its all meaningless. Go and real the POLICY documents behind them, the equivalent of the EULA and liability declarations. The issue of ''where'' is policy. If you miss out a SSL page they are not going to come and beat you up or take you to court for non-compliance. The ''dynamic'' seal is no different from any other such chunk of javascript-enabled dynamic update, like a clock or weather indicator. its not going to make your site more secure. What will make you site more secure has little to do with SSL. Much has been written on that and advising on it is about 30% of my business. There are good books and papers out there; google and amazon are your friends. SSL has many myths associated with it, and ''security'' is one of them. All it does is encrypt the link. Even this isn''t very good as there are many appliances sold as tools for corporate gateways that can spoof the connection in a way that is really a man-in-the-middle attack. If all you are doing is protecting what''s going on over the wire then a self-signed certificate is adequate. The Apache tools on my Linux box has all the stuff needed. I did this once, long ago, to try it out but s slips my memory right now. What companies like Verisign are selling is a form of trustworthiness. Even that is a chimera. Let me explain why. When you visit a site that purports to be Amazon and carry out a financial transaction you want to be sure that it really is Amazon you are dealing with, as well as securing the electrons over the wire. But if anyone can set up a self-signed cert then what? So we have ''certificate authorities'' like Verisign. The idea is that if the cert comes from Verisign then you can trust it. Why? Well, Verisign _should_ have verified that the company applying for the cert IS who they say there are, all the due diligence about their integrity, business practices, how they secure their network, their programming techniques, that they do own the domain and the IP addresses, and so on and so on and so on. All the stuff that I audit for in my "day job''. But the reality is that they actually sell a whole pile of grades of certs. Some of them you just have to apply for and pay the money - the only thing they check is that the credit card transaction goes through. This is not a put-down of Verisign or any other cert authority. Its marketing. Read the licensing agreements. Unless they are doing a due diligence check on you as a business then what you are getting offers no more protection than a self signed cert. However if you as a company need the marketing panash of displaying a known "badge" on your pages, then that''s another matter. The issue is WHAT ARE YOU TRYING TO ACHIEVE? The way you''ve worded your question is open. If its asking about technical superiority, then technically ANY SSL certificate is equivalent to any other - even a self signed one. -- Never look a gift horse in the mouth. Saint Jerome, On the Epistle to the Ephesians --~--~---------~--~----~------------~-------~--~----~ 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, I want to start by saying ''thanks.'' I really appreciate the time you spent on this excellent post. It''s very helpful to me. Anton Aylward wrote:> Go and real the POLICY documents behind them, the > equivalent of the EULA and liability declarations. > > The issue of ''where'' is policy.Excellent. That makes that easy. I''ll just do whatever they say I should do.> The ''dynamic'' seal is no different from any other such > chunk of javascript-enabled dynamic update, like a > clock or weather indicator.My site already uses a bunch of js; both handcoded and RJS. From what you''ve said I''m guessing it won''t pose any new problems if I decide to go the Dynamic route. If there are any technical gotcha''s you know of wrt Rails / Mongrel / etc., I''d sure appreciate hearing about them.> If all you are doing is protecting what''s going on over the > wire then a self-signed certificate is adequate. > <snip> > However if you as a company need the marketing panash > of displaying a known "badge" on your pages, then that''s > another matter.I need both the wire protection and the marketing panash.> The issue is WHAT ARE YOU TRYING TO ACHIEVE?Basics of the site are: Visitor enters or uploads/edits personal health information at my site, then saves it to their PC. I need to provide the visitor with a secure link during the time their personal information is in my site or in transit to my site from their PC or in transit from my site to them. I need to make sure their information doesn''t get cached along the way. The in-transit issues are the technical ones I''m tackling with SSL. In addition to the technical side, though, I''m also trying to give them something recognizable that confirms what I''ve told them I''m doing to protect their information while it''s in transit or on my site. So that''s where the badge comes in. Do you know if, from a marketing perspective, there''s any data on consumer perception of one over the other? I delete all their information from my site when they click the button that says ''Remove My Info'', or if their session goes inactive for 5 minutes. I know SSL has nothing to do with that but I''d like to do something equally as recognizable as the badge that provides confirmation that their data is in fact getting deleted as I say it is. Any thoughts on where to start looking for that would be very much appreciated. Thank you again for makiing the time to provide such a great reply. I really appreciate it. 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 -~----------~----~----~----~------~----~------~--~---
Bill Walton said the following on 02/28/2007 03:18 PM:> Hi Anton, > > I want to start by saying ''thanks.'' I really appreciate the time you spent > on this excellent post. It''s very helpful to me.I should be charging for this :-)> Anton Aylward wrote: > >> [big snip]> I need both the wire protection and the marketing panash.You need a LOT more, based on what I read from you.>> The issue is WHAT ARE YOU TRYING TO ACHIEVE? > > Basics of the site are: Visitor enters or uploads/edits personal health > information at my site, then saves it to their PC.Most places in the world you are also running into legal constraints as well as techncial ones. Speak to a lawyer. You will need a privacy & compliance notice on your site and and an explicit ''release'' from your users saying they understand and accept a whole pile of stuff. What stuff depends on the country, province or state you are in. SEE A LAYER.> I need to provide the visitor with a secure link during the time their > personal information is in my site or in transit to my site from their PC or > in transit from my site to them.That''s your basics.> I need to make sure their information > doesn''t get cached along the way.You can''t do that. You can''t control where they come from - they may not be using "their own" PC. They may be accessing from work, from a kiosk, from a library, from an internet café or from a rogue wireless connection in an airport waiting lounge. See http://www.intergovworld.com/Pages/Item/Article.aspx?id=f065d8b80a010408001a024c9ad85bf9 You have no control over where they access your site from, any firewalls, routers, proxies or anything else along the way. If one of those devices is something that, for example as part of their employers network infrastructure or the malicious machinations of the guy running the rogue wireless service (or the internet café for that matter) then tough. THAT is why you need a layer to write your if-but-maybe agreement.> The in-transit issues are the technical > ones I''m tackling with SSL. In addition to the technical side, though, I''m > also trying to give them something recognizable that confirms what I''ve told > them I''m doing to protect their information while it''s in transit or on my > site. So that''s where the badge comes in. Do you know if, from a marketing > perspective, there''s any data on consumer perception of one over the other?An immense amount of stuff but I don''t keep it to hand. I''d have to go through past magazine. Googling for it would be quicker. Try some InfoSec sites.> I delete all their information from my site when they click the button that > says ''Remove My Info'', or if their session goes inactive for 5 minutes. I > know SSL has nothing to do with that but I''d like to do something equally as > recognizable as the badge that provides confirmation that their data is in > fact getting deleted as I say it is. Any thoughts on where to start looking > for that would be very much appreciated.Other than asserting it and having them trust you, I can''t think of anything, and I can''t think why they should trust you, unless its some irrational extension of the the SSL badge. Rather like the people who think that the newspapers wouldn''t publish anything that wasn''t true. And, yes there are a lot of people out there who see the Internet like that or spamming wouldn''t be so profitable.> Thank you again for makiing the time to provide such a great reply. I > really appreciate it.You''re welcome. Now go see a layer. -- Never forget: The road to Hell is paved with good intentions. So tread hard on good intentions. -- rjd4 --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---