Hmmm, what specific bugs do you have in mind that would lead one to think
that one’s own implementation (once it meets the RFC) of SSL could lead to
compromises? If you follow the RFC you’re using assymmetric key exchange for
the main cipher key, and if you have bugs in your DH key exchange it usually
would mean that your keys wouldn’t work.
Or are you referring to possible man-in-the-middle attacks?
Anyway, happy new year.
Will
----- Original Message -----
From: “Arlie Davis”
To: “Windows File Systems Devs Interest List”
Sent: Wednesday, December 31, 2003 5:21 PM
Subject: RE: Re:[ntfsd] Pending specified file io makes system slow
> I know where all the RFCs and such are. I’m saying – if you implement
> a security protocol, you are implicitly guaranteeing to its users that
> it meets a certain level of security. And typically with security
> protocols, there is something at stake – if you fuck up, you may be
> financially liable to your users.
>
> I say again. Security protocols should only be implemented by
> professionals who know what they are doing, have the time to do it
> right, and have the time and resources to vigorously test and
> code-review their work. Ask anyone in the security profession –
> anything less is just asking for bugs. And bugs in security code often
> means total compromise.
>
> – arlie
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S.
> Shatskih
> Sent: Wednesday, December 31, 2003 8:03 PM
> To: Windows File Systems Devs Interest List
> Subject: Re: Re:[ntfsd] Pending specified file io makes system slow
>
>
> > Actually, that’s very bad advice, unless you have the time & money to
> > do intensive security reviews. Security protocols are notoriously
> > hard to get right.
>
> Take the RFC on SSL. If you really want the sample - take some GPL SSL
> code. Do not copy-paste from the code not belonging to you! Just use as
> a reference (as I did once with UUENCODE when my task was to write a
> web-based email system - I did not steal from GPL, first of all, GPL
> code was C and mine was C++ based on MFC’s CString class).
>
> You can even improve the GPL implementation as a side-effect 
>
> Use Windows CryptoAPI for crypto, unless you hit a bug in it. Hitting a
> bug in MS’s OS’s module is a VERY rare thing, I would say. No wonder
> they are concentrated around IE - in WININET etc. - IE is known to be
> the only security disaster among all MS’s products, so, no wonder.
>
> You must also notice that the “newer WININET is free from this bug” is
> not an excuse, since you limit the circle of your potential customers to
> ones with particular new IE version. The common task in modern
> commercial software development is to support the oldest system code
> base we can (that’s why the SCI’s main product is still built using NT4
> DDK - yes, we have the same BINARY running on NT OSes from NT4 to w2k3,
> and that’s why people are still writing VfW video capture drivers
> instead of DirectShow ones, even using hard-to-obtain Win95 DDK. Anyway
> DirectShow will wrap them around with QCAP.DLL).
>
> > Security development is a tricky business. Also, anyone who needs SSL
>
> > on Win32 should look at using the existing SSPI version.
>
> And if it is buggy?
>
> Sorry, I HATE buggy 3rd party components. I hate them very, very much,
> and - according to my practical experience - the decision of
> “re-implement!” made early saves a lot of
> patching/hacking/OIbscureBugHuntingInNonYourCode time.
>
> Surely, the sane project manager must have a clear answer to the “what
> NAMELY do we want to re-implement?” question. Oh yes, the RFCed SSL.
> Nothing proprietary or secret. All is open. There are implementations
> with sources. So what?
>
> > it’s a known, tested, reviewed product, and it works.
>
> It has a bug which is a major PITA for its user (the developer building
> the product on top of the feature).
>
> > working, it does the job. Oh, and if any bugs are found – they’re
> > Microsofts, not yours.
>
> OK, tell this to customers, and ask them to upgrade to newer IE. IMHO
> this is unprofessional a bit.
>
> “Your product does not work” - this is what the people say. They do not
> care the buggy WININET in some old IE - then want the product to work in
> their current system setup.
>
> Your own code has the advantage of being independent of what OS add-ons
> (and sometimes even what OS core modules) like IE are installed, and
> what versions they are.
>
> The advocates of pre-ready components often say this - “OK, if there
> will be a bug, this is our bug and not yours”. Fine. Let’s even assume
> they are responsible and fix their own bugs swiftly by issuing the new
> build versions.
>
> But anyway! their component is distributed as a module and is included
> to lots of products. So, the user will not necessary wish to upgrade
> this particular .DLL file.
>
> The “poor” developer who depend on their component can make an excuse of
> “well, upgrade to the FinestThirdPartyDLL.DLL version 4.1.3, our product
> will not work with 4.1.0”. So what? And if the person has 4.1.0 and is
> happy with it?
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@sublinear.org To
> unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> —
> Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@sftechserv.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com