September 11, 2018, 8:53 am
Personally, I opted for:
Code:
cert.set_serial_number(int.from_bytes(os.urandom(16), byteorder='big'))
This version is cryptographically secure, anything based on time or random is not.
↧
September 11, 2018, 1:13 pm
(Yesterday 03:53 PM)pepak Wrote: This version is cryptographically secure, anything based on time or random is not.
Thanks, that's better. I'm not a programmer myself, but I understand that time*random is dirty hack
![Smile!]( "Smile!")
↧
↧
September 12, 2018, 1:41 am
(Sep. 04, 2018 04:01 AM)JJoe Wrote: (Sep. 02, 2018 05:57 PM)vlad_s Wrote: Hello! I can not get the right column of two sites to be displayed https://vc.ru/ and https://tjournal.ru/
Code:
[SSL Pass-Thru]
vc.ru
tjournal.ru
Works for me but yuck.
(Sep. 09, 2018 02:01 PM)Sudenr Wrote: 5. When I try to download a picture from subdomain with an incorrect certificate, Firefox gives an error:
"SEC_ERROR_REUSED_ISSUER_AND_SERIAL"
It seems, that it's caused by identical serial number in generated certificates (and paranoid Firefox security), so I check how certs generated, and found line
Code:
cert.set_serial_number(int(time.time()*10000))
in CertTool.py and thats explains everything.
I changed it to
Code:
cert.set_serial_number(int(time.time()*random.randint(1, 10000)))
(yep, dirty hack), delete Certs folder and restart ProxHTTPSProxyMII.
No SSLv3 errors for 3 days.
I don't think I ever stumbled upon "SEC_ERROR_REUSED_ISSUER_AND_SERIAL" in the logs and I use Firefox almost exclusively, but maybe it was only my luck to visit some sites first before they were subdomains in others.
Anyways would this code change also fix problems with vc.ru and tjournal.ru so they would not need [SSL Pass-Thru]? Clearly they were subdomains in the shown example
EDIT:
OpenSSL now supports TLS1.3. Does that mean ProxHTTPSProxyMII would have to be updated to use this new updated library or OpenSSL-1.1.1 can be safely used?
more here:
https://www.openssl.org/blog/blog/2018/0...elease111/
↧
September 12, 2018, 3:41 am
I investigated for some time why msn.com page layout broke for me and it turns out it was due to one of the filters supplied by the meta_col.txt It had among them .local which made privoxy catch hyperlink such as locale= which was not what was intended. I suggest that those rules after the dot should end with / as they are meant for hosts anyways. For me changing it and other similar rules to .local/ fixed the issue.
↧
September 15, 2018, 9:16 pm
(Sep. 12, 2018 06:58 AM)ryszardzonk Wrote: I don't think I ever stumbled upon "SEC_ERROR_REUSED_ISSUER_AND_SERIAL" in the logs and I use Firefox almost exclusively, but maybe it was only my luck to visit some sites first before they were subdomains in others.
I did. Had to restart Firefox or re-generate the certificates when that happened.
It also seems that with this change, the quite frequent ResponseNotReady errors generated by ProxHTTPSProxy for some sites are a thing of the past. So I would quite recommend using this patch.
Quote:EDIT:
OpenSSL now supports TLS1.3. Does that mean ProxHTTPSProxyMII would have to be updated to use this new updated library or OpenSSL-1.1.1 can be safely used?
ProxHTTPSProxy does not need any change, but a modification may be necessary for the underlying OpenSSL bindings. Although a quick check suggest that the necessary change may already be in.
↧
↧
September 16, 2018, 11:38 am
(Sep. 12, 2018 06:58 AM)ryszardzonk Wrote: Anyways would this code change also fix problems with vc.ru and tjournal.ru so they would not need [SSL Pass-Thru]? Clearly they were subdomains in the shown example
Yes, just like subdomains. The proposed option in [SSL Pass-Thru] works, but this method is not desirable.
pepak, question to you or to someone who understands. I work on a router (ubuntu server 16.04). And sometimes there is an error that the certificate is not valid because of different time on the router and clients. Clients are synchronized from this router to NTP, but not always accurately, there is a difference of 0.5 seconds and this error occurs. I can not make exact synchronization of time. I wrote about this here
https://prxbx.com/forums/showthread.php?...5#pid19135
The question is, is it possible to specify the time when the certificate should start validating more early, rather than at the time the certificate was generated?
↧
September 16, 2018, 6:17 pm
(Yesterday 06:37 PM)vlad_s Wrote: is it possible to specify the time when the certificate should start validating more early, rather than at the time the certificate was generated?
Yep. In CertTool.py change lines
Code:
cert.gmtime_adj_notBefore(0)
to
Code:
cert.gmtime_adj_notBefore(-60 * 60 * 24 * 2)
and all your new certificates will be generated two days ago from current time
↧
September 16, 2018, 6:21 pm
There are also one thing that bothers me. Don't you think, that default encryption between browser and ProxHTTPSProxyMII is too powerful? Really, AES256-GCM for localhost is a little... excessively.
Ciphersuite for connection to front-proxy can be set in ProxHTTPSProxy.py line
Code:
ssl_sock = ssl.wrap_socket(self.connection, keyfile=dummycert, certfile=dummycert, server_side=True)
by change it like
Code:
ssl_sock = ssl.wrap_socket(self.connection, ciphers='ECDHE-ECDSA-AES128-GCM-SHA256', keyfile=dummycert, certfile=dummycert, server_side=True)
It's better to use
ECDHE-ECDSA-AES128-GCM-SHA256 if CPU have AES-NI,
ECDH+CHACHA20 if AES acceleration unavailable or even
!aNULL for avoiding double encrypt-decrypt if connection security managed by upstream proxy like
compy
So, maybe ciphersuite selection option should be placed in config.ini as advanced option?
↧
September 17, 2018, 5:34 am
(Yesterday 01:15 AM)Sudenr Wrote: (Sep. 16, 2018 06:37 PM)vlad_s Wrote: is it possible to specify the time when the certificate should start validating more early, rather than at the time the certificate was generated?
Yep. In CertTool.py change lines
Code:
cert.gmtime_adj_notBefore(0)
to
Code:
cert.gmtime_adj_notBefore(-60 * 60 * 24 * 2)
and all your new certificates will be generated two days ago from current time
Ok, it works.
↧
↧
September 19, 2018, 9:38 am
It is impossible to open the site just.ru and rbt.ru, while in the section [SSL Pass-Thru] is not added *.variti.de. The script from *.variti.de is loaded normally in any case. So I did not understand who was to blame for the privoxy or proxhttpsproxy.
↧
September 20, 2018, 12:28 am
(Sep. 19, 2018 04:38 PM)vlad_s Wrote: who was to blame for the privoxy or proxhttpsproxy.
Privoxy. I do not use it's default filters and actions, and both sites load normally.
↧
September 20, 2018, 8:59 am
In the config privoxy I commented out all filter and action and it did not help
![Sad]( "Sad")
. Only the [SSL Pass-Thru] section helps, then *.variti.de can be removed from there and some time works.
↧
September 20, 2018, 11:03 am
Did you try regenerate *.variti.de certificate? What's in your ProxHTTPSProxy log, when you go to variti.de?
↧
↧
September 21, 2018, 5:03 am
(Sep. 17, 2018 01:20 AM)Sudenr Wrote: There are also one thing that bothers me. Don't you think, that default encryption between browser and ProxHTTPSProxyMII is too powerful? Really, AES256-GCM for localhost is a little... excessively.
Ciphersuite for connection to front-proxy can be set in ProxHTTPSProxy.py line
Code:
ssl_sock = ssl.wrap_socket(self.connection, keyfile=dummycert, certfile=dummycert, server_side=True)
by change it like
Code:
ssl_sock = ssl.wrap_socket(self.connection, ciphers='ECDHE-ECDSA-AES128-GCM-SHA256', keyfile=dummycert, certfile=dummycert, server_side=True)
It's better to use ECDHE-ECDSA-AES128-GCM-SHA256 if CPU have AES-NI, ECDH+CHACHA20 if AES acceleration unavailable or even !aNULL for avoiding double encrypt-decrypt if connection security managed by upstream proxy like compy
So, maybe ciphersuite selection option should be placed in config.ini as advanced option?
Unfortunately I don't think many, if any, browsers will like to use null SSL. Perhaps the weakest cipher they accept would be ideal, but that seems to change frequently.
↧
September 21, 2018, 9:50 am
(Yesterday 12:03 PM)amy Wrote: Unfortunately I don't think many, if any, browsers will like to use null SSL. Perhaps the weakest cipher they accept would be ideal, but that seems to change frequently.
It's not for browsers, it's for another proxy, if they encrypt connection by themselves.
↧
September 23, 2018, 3:42 pm
(Sep. 20, 2018 06:03 PM)Sudenr Wrote: Did you try regenerate *.variti.de certificate? What's in your ProxHTTPSProxy log, when you go to variti.de?
With proxhttps, the script loads, if I just try to download it (by link). But when I open those sites, the problem also arises. The log is empty (no errors).
↧
September 25, 2018, 1:39 pm
(Sep. 23, 2018 10:42 PM)vlad_s Wrote: The log is empty (no errors).
Open browser network console (F12) and reload page. Is there CORS related errors?
↧
↧
September 25, 2018, 10:33 pm
love what you've done with proxomitron.
(Sep. 05, 2018 03:10 AM)amy Wrote: Currently ( since 4.5j at least) it supports a sort of weird "silent half-SSL" mode where you can connect to it on 8080 and then send it an HTTPS URL, and it then makes an encrypted connection to the site but communication between browser and proxy is still unencrypted. In other words the browser doesn't need to support HTTPS, but it can access those sites through Proxomitron. I'm not sure if any browsers do or can be configured to do this.
half-SSL is kinda cool. sidki added it to his config set and I still use it that way on a browser where I can block ssl connections. There are caveats and limitations to doing this, but it's enough that I never bothered with chaining ProxHTTPSProxy to proxomitron.
When using half-ssl with proxo reborn there's a bug where the Host header contains the half-ssl proxy prefix. For example, this site's Host header appears:
Host: https-px-.www.prxbx.com
You can reproduce the bug using sidki's latest config set, sidki_2011-12-22rc1, and turning on the half-ssl filters
https://www.prxbx.com/forums/showthread.php?tid=1870
↧
September 28, 2018, 11:11 pm
What is the latest version of Firefox has been released is there any interesting theme for it
↧
September 29, 2018, 12:27 am
(Sep. 25, 2018 08:39 PM)Sudenr Wrote: (Sep. 23, 2018 10:42 PM)vlad_s Wrote: The log is empty (no errors).
Open browser network console (F12) and reload page. Is there CORS related errors?
There are no errors, just the script with variti.de reloads all the time.
↧
. Only the [SSL Pass-Thru] section helps, then *.variti.de can be removed from there and some time works.