On 5/20/20 3:51 AM, David Touzeau wrote: > How to be a sponsor? There are many ways, including these two: 1. You privately find a developer (a person or an organization) and pay them for implementing the changes you need. 2. You post an RFQ to squid-dev and solicit quotes/bids from developers. If substantial changes you sponsored are officially accepted, you can request to be officially listed in SPONSORS. Needless to say, you can pull resources with other co-sponsors. For a complex feature like TLS-inside-TLS bumping, please make sure that a) The required architectural changes are deemed acceptable to the Squid Project before the development starts. Otherwise, you may end up with a large piece of code that you would have to pay somebody to maintain forever. Such preliminary acceptance can be secured via discussions on squid-dev. Such discussions should be initiated by (the developer) posting a Request For Comments outlining major anticipated changes. b) The developer will support the changes throughout Squid Project review and initial deployment. It is very likely that the initial version of the "working" code will need to be adjusted (for many reasons). The following FAQ may be useful in this context: https://wiki.squid-cache.org/SquidFaq/AboutSquid#How_to_add_a_new_Squid_feature.2C_enhance.2C_of_fix_something.3F > ( cost ) of such feature That would be determined by the developer, subject to the usual business negotiations (warranties, deadlines, backporting support, payment terms, etc.). The most common pitfalls here are underestimating the complexity of the changes, the overheads related to getting the changes officially accepted, and medium-term support costs. FWIW, if I were to get a quote that equates this project with a week worth of work, I would laugh at it. Please note that the Squid Project itself does not do Squid development and does not receive any money for Squid development. Some developers contribute back to the Project (in various ways), but there is no requirement to do so. This is typical for many open source projects, of course. > Could you think it can be planned for 5.x ? IMO, no. The change is too big to qualify for any reasonable v5 freeze exception. Squid v6 is your best bet right now. If the developer knows what they are doing, there are ways to mitigate associated risks. HTH, Alex. > Le 19/05/2020 à 16:46, Alex Rousskov a écrit : >>>> On 18/05/20 10:15 am, David Touzeau wrote: >>>>> Hi we want to use squid as * * * Secure Proxy * * * using https_port >>>>> We have tested major browsers and it seems working good. >>>>> >>>>> To make it work, we need to deploy the proxy certificate on all browsers >>>>> to make the secure connection running. >> I hope that deployment is not necessary -- an HTTPS proxy should be >> using a certificate issued for its domain name and signed by a >> well-known CA already trusted by browsers. An HTTPS proxy is not faking >> anything. If browsers do require CA certificate import in this >> environment, it is their limitation. >> >> >> On 5/19/20 9:24 AM, Matus UHLAR - fantomas wrote: >>> David, note that requiring browsers to connect to your proxy over encrypted >>> (https) connection, and then decrypting tunnels to real server will lower >>> the clients' security >> A proper SslBump implementation for HTTPS proxy will not be "decrypting >> tunnels to real server". The security of such an implementation will be >> the same as of SslBump supported today (plus the additional protections >> offered by securing the browser-proxy communication). >> >> Cheers, >> >> Alex. _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
