Chrome tvingar SSL kryptering

Permalänk
Medlem

Chrome tvingar SSL kryptering

Hej!

Har ett störande problem jag inte riktigt kan få bukt med. När jag försöker surfa in på en viss adress tvingar chrome SSL kryptering. Istället för http://192.168.1.150:9091 hamnar jag på https://192.168.1.150:9091, denna tjänst existerar dock ej. Några förslag på hur jag kan få bort det? Vill inte behöva rensa all historik eller något för att lösa det. Just nu löser jag det genom att använda en annan webläsare (Safari). Kan nämnda att detta har tidigare fungerat, men började dumma sig. Det började dumma sig i samband med att jag hade ett force SSL plugin (dock inte aktiverat på denna sida), som jag senare tog bort. Tjänsten jag försöker komma åt är transmission web client.

Permalänk
Hedersmedlem

Händer det även om du inaktiverar tilläggsprogram (exempelvis startar med `--disable-extensions`)?

Visa signatur

Nu med kortare användarnamn, men fortfarande bedövande långa inlägg.

Permalänk
Medlem
Skrivet av phz:

Händer det även om du inaktiverar tilläggsprogram (exempelvis startar med `--disable-extensions`)?

Den väljer att gå in via https då också.

Permalänk
Entusiast
Skrivet av trexake:

Den väljer att gå in via https då också.

Låter som om det är servicen bakom port 9091 som tvingar in den omdirigeringen. Inte webbläsaren.
Om jag inte missminner mig, är den porten populär för fjärrstyrning av torrent-klienter, såsom transmission med flera.
Kolla i programmet som erbjuder servicen bakom den porten, och se om den kan ställas om till en icke krypterad webb-service.

Torrent-klienter brukar oftast tvinga in en krypterad anslutning till sina fjärrstyrnings-sidor per standard.

Tillägg:
Har hört att kvarvarande cookies kan ställa till det. Prova att ta bort alla cookies relaterade till den tjänsten, och prova igen.

Visa signatur

Bästa programmen till Linux - v2.0
Linux-guide: Val av grafisk miljö. (Att välja distribution).
-
Everyone should have a SGoC in their systems (SGoC: SysGhost on a Chip)

Permalänk
Medlem
Skrivet av SysGhost:

Låter som om det är servicen bakom port 9091 som tvingar in den omdirigeringen. Inte webbläsaren.
Om jag inte missminner mig, är den porten populär för fjärrstyrning av torrent-klienter, såsom transmission med flera.
Kolla i programmet som erbjuder servicen bakom den porten, och se om den kan ställas om till en icke krypterad webb-service.

Torrent-klienter brukar oftast tvinga in en krypterad anslutning till sina fjärrstyrnings-sidor per standard.

Tillägg:
Har hört att kvarvarande cookies kan ställa till det. Prova att ta bort alla cookies relaterade till den tjänsten, och prova igen.

Det stämmer att det är en torrent-klient (transmission). Jag har inte ställt in någonting om kryptering, och detta har fungerat fint tidigare, det finns heller ingenting om kryptering i konfigurationsfilen. Problemet uppstår endast med webläsaren chrome.

"alt-speed-down": 50, "alt-speed-enabled": false, "alt-speed-time-begin": 540, "alt-speed-time-day": 127, "alt-speed-time-enabled": false, "alt-speed-time-end": 1020, "alt-speed-up": 50, "bind-address-ipv4": "0.0.0.0", "bind-address-ipv6": "::", "blocklist-enabled": false, "blocklist-url": "http://www.example.com/blocklist", "cache-size-mb": 4, "dht-enabled": true, "download-dir": "/tank/Serier", "download-queue-enabled": true, "download-queue-size": 10, "encryption": 1, "idle-seeding-limit": 30, "idle-seeding-limit-enabled": false, "incomplete-dir": "/tank/Incomplete", "incomplete-dir-enabled": true, "lpd-enabled": false, "message-level": 2, "peer-congestion-algorithm": "", "peer-id-ttl-hours": 6, "peer-limit-global": 200, "peer-limit-per-torrent": 50, "peer-port": 51413, "peer-port-random-high": 65535, "peer-port-random-low": 49152, "peer-port-random-on-start": false, "peer-socket-tos": "default", "pex-enabled": true, "pidfile": "/var/run/transmission/daemon.pid", "port-forwarding-enabled": true, "preallocation": 1, "prefetch-enabled": 1, "queue-stalled-enabled": true, "queue-stalled-minutes": 30, "ratio-limit": 2, "ratio-limit-enabled": false, "rename-partial-files": true, "rpc-authentication-required": true, "rpc-bind-address": "0.0.0.0", "rpc-enabled": true, "rpc-password": "{68a43cd85fd5582ee052135b5944da51eb672d72A1zz3g.H", "rpc-port": 9091, "rpc-url": "/transmission/", "rpc-username": "transmission", "rpc-whitelist": "127.0.0.1,192.168.1.*", "rpc-whitelist-enabled": true, "scrape-paused-torrents-enabled": true, "script-torrent-done-enabled": false, "script-torrent-done-filename": "", "seed-queue-enabled": false

Citat:

Tillägg:
Har hört att kvarvarande cookies kan ställa till det. Prova att ta bort alla cookies relaterade till den tjänsten, och prova igen.

Detta tror jag på, ska kolla på det. Tog bort cookies för 192.168.1.150 enligt http://www.tech-recipes.com/rx/3016/google_chrome_how_to_dele... . Hjälpte dock inte, tror snarare det ligger i historiken kring den sidan. Ska testa ta bort det.

På port 443 har jag en webserver igång med SSL kryptering, men det borde inte spela någon roll. Feler ligger i chrome. Någon gång i december slutade detta att fungera. Då jag har kört via localhost är när jag har kört via SSH tunnel utifrån mitt nätverk.

Permalänk
Entusiast

Jag lyckas inte replikera problemet. Använder själv Transmission och senaste Google Chrome.
Kolla om det hjälper med att logga in med en annan (skapa ny?) användare på din dator.
Om det hjälper, tyder det på inställningsproblem i chrome. Om inte så är det något med den version av google chrome och/eller transmission.

Prova även att bokstavligen skriva "http://" före den akutella adressen. Om omdirigering fortfarande sker, så är det transmission egna webbserver som begär den omdirigeringen. Eller så är den ett plugin och/eller extension som forcerar krypterad anslutning. Är det inte det så är det högst mystiskt. Prova att nollställa alla inställningarna till Chrome helt och hållet kanske funkar?

Något mer ni kan prova är att installera Google Chrome beta, och se om den senaste beta-versionen "avhjälper" problemet.

Visa signatur

Bästa programmen till Linux - v2.0
Linux-guide: Val av grafisk miljö. (Att välja distribution).
-
Everyone should have a SGoC in their systems (SGoC: SysGhost on a Chip)

Permalänk
Medlem

Jag hade samma problem hemma, var tvungen att rensa historiken för att det skull gå att komma åt sidan.

I mitt fall hade jag dock tvingad omdirigering till https:// för routern och efter jag stängde av den tvingade dirigeringen blev det automatiskt https ändå.

Permalänk
Medlem

Det blir samma resultat när jag bokstavligen skriver http://. Det tas bort och https:// läggs till. Det är förmodligen någon inställning i chrome som ligger och spökar, eller att någonting inte är borttaget helt sedan force SSL pluginet. Kör jag med chrome via mobilen fungerar det bra (all data synkas dit i princip).

Testade följande:

Simons-MacBook-Pro:Downloads sijohans$ nc -z 192.168.1.150 9091 Connection to 192.168.1.150 port 9091 [tcp/xmltec-xmlmail] succeeded!

Testar att hämta data via curl:

curl -o test.html http://192.168.1.150:9091

Då får jag inga SSL fel, unauthorized user (man måste ju logga in på transmission). Detta är felmeddelandet chrome ger:

SSL connection error Hide details Unable to make a secure connection to the server. This may be a problem with the server, or it may be requiring a client authentication certificate that you don't have. Error code: ERR_SSL_PROTOCOL_ERROR

Jag har ju ett eget signerat SSL certifikat, men det är för webserver på en helt annan port. Men kanske chrome tror att det ska vara krypterat då det finns för den IPn? Det ligger i och för sig i operativsystemets (OsX) nyckelkedja. Börjar på att få testa rensa all historik och dylikt, det är lite trist dock.

Hehe, kollade precis hur många visningar denna tråd hade, 443. Kan det vara en slump?

Permalänk
Medlem

Jag löste det nu genom att radera all historik och all sparad data, lite tråkigt att man var tvungen att gå den vägen. Finns en del andra saker jag hade kunnat leta i, de som visas på denna sida till exempel: http://crunchify.com/how-to-purge-all-your-google-chrome-user...

hade kunna söka efter data specifikt för den adressen eventuellt och ta bort det.