January 2026
M	T	W	T	F	S	S
	1	2	3	4
5	6	7	8	9	10	11
12	13	14	15	16	17	18
19	20	21	22	23	24	25
26	27	28	29	30	31

Archive for the ‘TLS’ Category

Some links on Chrome not prompting to save passwords (when Firefox and Safari do)

Posted by jpluimers on 2022/01/20

For quite some time now, Chrome (think years) refuses to prompt for saving passwords whereas Firefox and Safari do prompt and save them, even for site types that it used to save passwords for in the past.

It has been annoying enough for too long now that I tried to do better than the Google searches I used back when I saw this happen first.

Below are some links based on new searches (starting with [Wayback] adding a password in chrome settings – Google Search); hopefully I can try them after I made a list of sites that Chrome does not show the password save prompt for.

Solutions I tried that failed (but maybe useful for others):

[Wayback] windows 7 – Chrome not asking to remember passwords – Super User: restart your browser
First answer of [Wayback] How can I manually add a password to Chrome password manager? – Super User : check if “Autofill” a.k.a. “Offer to save passwords” is enabled and the site is not on the “Never Saved” list of sites.
Second answer of [Wayback] How can I manually add a password to Chrome password manager? – Super User Check if there is a password input field being marked with type="password", and if not add it.

Solutions still to try:

Read the rest of this entry »

Posted in Chrome, Chrome, Communications Development, Development, Encryption, ESXi6, ESXi6.5, ESXi6.7, Firefox, Fritz!, Fritz!Box, Fritz!WLAN, Google, https, HTTPS/TLS security, Internet, Internet protocol suite, Let's Encrypt (letsencrypt/certbot), Power User, routers, Safari, Security, TCP, TLS, Virtualization, VMware, VMware ESXi, Web Browsers, Web Development | Leave a Comment »

Which SMTP Port Should I Use? Learn Ports 25, 465, & 587 (and unofficial port 2525) | Mailgun

Posted by jpluimers on 2021/11/30

When trying to deliver mail, it is important to know which protocols and ports you can use.

On smtp, smtp-submission, smtps (ports 25, 587 and 465) and unofficial port 2525 (which Maingun maps to `smtp-submission): [Wayback] Which SMTP Port Should I Use? Learn Ports 25, 465, & 587 | Mailgun

Quote on why smtps port 465 is hardly used:

Port 465:

IANA has reassigned a new service to this port, and it should no longer be used for SMTP communications.

However, because it was once recognized by IANA as valid, there may be legacy systems that are only capable of using this connection method. Typically, you will use this port only if your application demands it. A quick Google search, and you’ll find many consumer Inbox Service Providers’ (ISPs) articles that suggest port 465 as the recommended setup. However, we do not recommend it, as it is not RFC compliant.

–jeroen

Posted in Communications Development, Development, Internet protocol suite, SMTP, Software Development, TLS, Web Development | Leave a Comment »

The browser wars that started on iOS (forcing Safari) and Android (forcing Chrome) now are continued on Windows 11 (forcing Edge)

Posted by jpluimers on 2021/10/05

iOS has forced Safari to be the only web browser since forever, so Google started to use the googlechrome: scheme to force Chrome as browser on it a while ago
Android has forced Chrome to be the only Web View since forever, but application specific URI prefixes can launch specific browsers and are heavily used (see for instance [Wayback/Archive.is] android – Launching an App from a URL – Stack Overflow where the answer explains how to route the example: scheme to an application)
Windows 11 now uses the microsoft-edge: scheme even more than Windows 10 to force URIs to open in Edge, and some browsers are now working around this

Via:

[Archive.is] Jeroen Wiert Pluimers on Twitter: “The browser wars that started on iOS (forcing Safari) and Android (forcing Chrome) now are continued on Windows 11 (forcing Edge): … “
- [Wayback/Archive.is] Brave and Firefox to intercept links that force-open in Microsoft Edge
  - Implement microsoft-edge: protocol handler, issue #1726697, 2021-09-30, Masatoshi Kimura, Firefox project, Bugzilla, Mozilla
  - When Brave handles microsoft-edge: protocol searches use user’s default search instead of Bing, issue #17684, 2021-08-25, Brian Clifton, Brave browser project, Brave Software, GitHub
  - Allow Brave to Handle Searches from Windows Shell and Cortana, issue #13875, 2021-09-24, Brave browser project, Brave Software, GitHub
  - microsoft_edge_protocol_util.cc, commit a80e1ea7b6, 2021-09-24, Simon Hong, Brave Core project, Brave Software, GitHub
  - Mozilla has defeated Microsoft’s default browser protections in Windows, 2021-09-13, Tom Warren, The Verge, Vox Media
  - Microsoft is making it harder to switch default browsers in Windows 11, 2021-08-18, Tom Warren, The Verge, Vox Media
  - Opening links in Chrome for iOS, 2014-02-28, Mobile Chrome, Documentation, Chrome Developers, Google
[Archive.is] Kristian Köhntopp on Twitter: “… Niemand will Edge, außer Microsoft, also fangen die Browserkriege wieder an. Juhu, wie ich es vermisst habe.”
- [Archive.is] Edge-Links: Brave und Mozilla fangen die spezifischen Verweise ab – Golem.de
  - Firefox: [Wayback/Archive.is] 1726697 – Implement `microsoft-edge:` protocol handler
[Archive.is] Jeroen Wiert Pluimers on Twitter: “Regardless if you like Edge or not (there are pros and cons to both), I dislike this kind of browser war as the OS and apps should be fully configurable as to which browser is used (Android WebView is still Chrome and I dislike that too).… “

Posted in Awareness, Development, HTTP, Internet protocol suite, Software Development, TCP, TLS, URI, Web Development | Leave a Comment »

One of the Let’s Encrypt’s Root Certificates expired today (and their corresponding intermediate yesterday); how is your infrastructure doing?

Posted by jpluimers on 2021/09/30

Last weekend I published 5 days before the Let’s Encrypt’s Root Certificate is expiring!

It basically was a post trying to amplify the [Wayback/Archive.is] Let’s Encrypt’s Root Certificate is expiring! message by [Wayback] Scott Helme .

Yesterday and today, he is maintaining a Twitter thread on things that have broken.

Quite a few things have, including some versions of curl, on which a lot of infrastructure relies (the certificate for it got fixed later on 20120930), see:

Two important starting points in his thread:

If you want to check from one of your own clients, try [Archive.is] Scott Helme on Twitter: “I’ve created a test site to help identify issues with clients. If you can connect to https://t.co/bXHsnlRk8D then your client can handle being served the expired R3 Intermediate in the server chain!… “

[Wayback/Archive.is] https://expired-r3-test.scotthelme.co.uk/

Note that neither SSLabs, nor Cencys, nor CertCheckkerApp do show the expired certificate, only the new one:

Yes, I know the pluimers.com web server is rated B from a TLS perspective. Will be working on it, but I’m still recovering from rectum cancer treatments, and have an almost 1.5 year backlog to get through.

–jeroen

Posted in Communications Development, Development, Encryption, HTTP, https, HTTPS/TLS security, Internet protocol suite, Let's Encrypt (letsencrypt/certbot), Power User, Security, Software Development, TCP, TLS, Uncategorized, Web Development | Leave a Comment »

5 days before the Let’s Encrypt’s Root Certificate is expiring!

Posted by jpluimers on 2021/09/24

Only 5 days left to take a close look at both your web-clients (including back-end clients!) and servers to prevent potential Let’s Encrypt mayhem.

Last week, [Wayback] Scott Helme published about [Wayback/Archive.is] Let’s Encrypt’s Root Certificate is expiring!

Let’s Encrypt has done loads of work over the past lustrum to prevent trouble like cross-signing, issuing the successor certificates, and more.

The problem is that people like you and me have refrained from keeping their clients and servers up-to-date, so some security issues will occur. Hopefully they are limited to non-functioning communication and not leaking of data.

It is about this DST Root CA X3 certificate, used by the vast majority of Let’s Encrypt certificates, [Wayback/Archive.is] Certificate Checker: CN=DST Root CA X3, O=Digital Signature Trust Co.:

DST Root CA X3

Certificate Trusted anchor certificate

Subject DN CN=DST Root CA X3, O=Digital Signature Trust Co.

Issuer DN CN=DST Root CA X3, O=Digital Signature Trust Co.

Serial Number 44AFB080D6A327BA893039862EF8406B

Valid September 30, 2000 to September 30,
2021 Key RSAPublicKey (2048 bit)

SHA1 Hash DAC9024F54D8F6DF94935FB1732638CA6AD77C13 MD5 Hash 410352DC0FF7501B16F0028EBA6F45C5

SKI C4A7B1A47B2C71FADBE14B9075FFC41560858910 AKI

DST Root CA X3
Certificate	Trusted anchor certificate
Subject DN	CN=DST Root CA X3, O=Digital Signature Trust Co.
Issuer DN	CN=DST Root CA X3, O=Digital Signature Trust Co.
Serial Number	`44AFB080D6A327BA893039862EF8406B`
Valid	September 30, 2000 to September 30, 2021	Key	RSAPublicKey (2048 bit)
SHA1 Hash	`DAC9024F54D8F6DF94935FB1732638CA6AD77C13`	MD5 Hash	`410352DC0FF7501B16F0028EBA6F45C5`
SKI	`C4A7B1A47B2C71FADBE14B9075FFC41560858910`	AKI

Quoting Scott, these clients likely will fail, so need attention:

OpenSSL <= 1.0.2

Windows < XP SP3

macOS < 10.12.1

iOS < 10 (iPhone 5 is the lowest model that can get to iOS 10)

Android < 7.1.1 (but >= 2.3.6 will work if served ISRG Root X1 cross-sign)

Mozilla Firefox < 50

Ubuntu < 16.04

Debian < 8

Java 8 < 8u141

Java 7 < 7u151

NSS < 3.26

Amazon FireOS (Silk Browser)

On the server side, you can help Android devices by using a Let’s Encrypt certificate that is cross-signed with the ISRG Root X1 certificate [Wayback/Archive.is] Certificate Checker: CN=ISRG Root X1, O=Internet Security Research Group, C=US:

ISRG Root X1

Certificate

Subject DN CN=ISRG Root X1, O=Internet Security Research Group, C=US

Issuer DN CN=DST Root CA X3, O=Digital Signature Trust Co.

Serial Number 4001772137D4E942B8EE76AA3C640AB7

Valid January 20, 2021 to September 30, 2024 Key RSAPublicKey (4096 bit)

SHA1 Hash 933C6DDEE95C9C41A40F9F50493D82BE03AD87BF MD5 Hash C1E1FF07F9F688498274D1A18053EABF

SKI 79B459E67BB6E5E40173800888C81A58F6E99B6E AKI C4A7B1A47B2C71FADBE14B9075FFC41560858910

ISRG Root X1
Certificate
Subject DN	CN=ISRG Root X1, O=Internet Security Research Group, C=US
Issuer DN	CN=DST Root CA X3, O=Digital Signature Trust Co.
Serial Number	`4001772137D4E942B8EE76AA3C640AB7`
Valid	January 20, 2021 to September 30, 2024	Key	RSAPublicKey (4096 bit)
SHA1 Hash	`933C6DDEE95C9C41A40F9F50493D82BE03AD87BF`	MD5 Hash	`C1E1FF07F9F688498274D1A18053EABF`
SKI	`79B459E67BB6E5E40173800888C81A58F6E99B6E`	AKI	`C4A7B1A47B2C71FADBE14B9075FFC41560858910`

Via [Archive.is] Scott Helme on Twitter: “There are only 10 days left until the Let’s Encrypt root certificate expires and there are still questions over what the impact will be! Full details here: …” which links to the above article showing a nice graph of the current Let’s Encrtypt root certificate setup:

–jeroen

Posted in Communications Development, Development, Encryption, https, HTTPS/TLS security, Internet protocol suite, Let's Encrypt (letsencrypt/certbot), Power User, Security, Software Development, TCP, TLS, Web Development | Leave a Comment »

Tricks used by software developers to https://127.0.0.1

Posted by jpluimers on 2021/09/07

Long interesting thread at [WayBack] Thread by @sleevi_: “@SwiftOnSecurity So, some history: It used to be folks would get certs for “localhost”, just like they would from “webmail”, despite no CA e […]”

In 2019, applications were still using tricks (including shipping private keys!) to “securely” access https://127.0.0.1 on some port.

This should have stopped in 2015, but hadn’t. I wonder how bad it still is today.

[WayBack] SwiftOnSecurity on Twitter: “Me: Threat-hunting rare DNS lookups in a corporate network. Confluence: … “

[WayBack] Tavis Ormandy on Twitter: “This turned out to be a real vulnerability! 😮 The certificate was issued by @digicert, who are now required to revoke it. It was issued before mandatory CT, so didn’t show up in …. See … for context.…”
[WayBack] Ryan Sleevi on Twitter: “So, some history: It used to be folks would get certs for “localhost”, just like they would from “webmail”, despite no CA ever having validated the name. They just relied on pinky promises to be good. Luckily, browsers forbid that … “
[WayBack] Ryan Sleevi on Twitter: “Look at the dates on those. Yes, it’s a things CAs used to do, and they had to be dragged kicking and screaming into not doing it (and even then, *many* ignored/“oopsied” the requirement to revoke). I regret to inform you it didn’t stop until 2015/2016 – … “
[WayBack] Guidance on Internal Names – CAB Forum
[Archive.is] HTTPS encryption on the web – Google Transparency Report: atlassian-domain-for-localhost-connections-only.com
[Archive.is] HTTPS encryption on the web – Google Transparency Report
- SubjectC=AU, O=Atlassian Pty Ltd, L=Sydney, ST=New South Wales, CN=atlassian-domain-for-localhost-connections-only.com
- Serial NumberA:3E:93:53:0E:74:53:AE:CB:40:BA:20:10:12:F8:FB
- IssuerC=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert SHA2 High Assurance Server CAValidity11 May 2017 — 15 May 2020
The domain is (at the time of writing, so hopefully that is now “was”) used by the [WayBack] Administering the Atlassian Companion App – Atlassian Documentation
- [WayBack] Companion App doesnt work in corporate network.

At the time of writing, the interactive Google DNS showed the domain pointing to localhost [WayBack] Google Public DNS:

Result for atlassian-domain-for-localhost-connections-only.com/A with DNSSEC validation:

{
  "Status": 0,
  "TC": false,
  "RD": true,
  "RA": true,
  "AD": false,
  "CD": false,
  "Question": [
    {
      "name": "atlassian-domain-for-localhost-connections-only.com.",
      "type": 1
    }
  ],
  "Answer": [
    {
      "name": "atlassian-domain-for-localhost-connections-only.com.",
      "type": 1,
      "TTL": 1620,
      "data": "127.0.0.1"
    }
  ]
}

[Archive.is/WayBack] SSL Server Test: atlassian-domain-for-localhost-connections-only.com (Powered by Qualys SSL Labs)

Assessment failed: IP address is from private address space (RFC 1918)

Read the rest of this entry »

Posted in Communications Development, Development, DNS, HTTP, Internet, Power User, Software Development, TCP, TLS | Leave a Comment »

For my link archive: DNS over https

Posted by jpluimers on 2021/09/02

DNS over HTTPS

For my link archive:

DNS over HTTPS – Wikipedia / Public recursive name server – Wikipedia
[WayBack] RFC 8484 – DNS Queries over HTTPS (DoH)
- [WayBack] DNS Queries over HTTPS
- [WayBack] GitHub – dohwg/draft-ietf-doh-dns-over-https: Discussion of draft-ietf-doh-dns-over-https in the IETF’s DOH Working Group
[WayBack] DNS over HTTPS · curl/curl Wiki · GitHub (which has a list of publicly available servers)
[WayBack] A cartoon intro to DNS over HTTPS – Mozilla Hacks – the Web developer blog
[WayBack] DNS over HTTPS – Cloudflare Resolver

JSON DNS output

Some DNS over HTTSP providers support dns-json, which Cloudflare delivers non-pretty printed.

Read the rest of this entry »

Posted in Cloud, Cloudflare, Communications Development, Development, DNS, Encryption, HTTP, https, HTTPS/TLS security, Infrastructure, Internet, Internet protocol suite, Power User, Security, Software Development, TCP, TLS | Leave a Comment »

How to configure Nginx SSL/TLS passthrough with TCP load balancing – nixCraft

Posted by jpluimers on 2018/10/17

Explains how to configure Nginx with SSL Passthrough on Linux or Unix-like system to encrypt traffic on all backends.

Uses the stream module ngx_stream_core_module.

Source: [WayBack] How to configure Nginx SSL/TLS passthrough with TCP load balancing – nixCraft

via: [WayBack] Learn how to setup TCP load balancing with Nginx and configure SSL Passthrough on Linux/Unix. – nixCraft – Google+

–jeroen

Read the rest of this entry »

Posted in Communications Development, Development, HTTP, Internet protocol suite, TCP, TLS | Leave a Comment »

Packet Sender is a good tool when debugging protocols: free utility to send & receive network packets. TCP, UDP, SSL

Posted by jpluimers on 2018/03/07

It was fitting to bump into [WayBack] Packet Sender is a good tool when debugging protocols…” Written by Dan Nagle… – Lars Fosdal – Google+ on the day presenting [WayBack] Conferences/Network-Protocol-Security.rst at master · jpluimers/Conferences · GitHub

It also means that libssh2-delphi is getting a bit more love soon and will move to github as well after a conversion from mercurial.

Some of the things I learned or got confirmed teaching the session (I love learning by teaching):

Automate the heck out of your job and new work finds you
There is great integration for [WayBack] Bot Users | Slack which can hugely help you in status monitoring
If you manage many domains, which might be troublesome to the default “certbot client”, so you might want to look into different [WayBack] ACME Client Implementations – Let’s Encrypt – Free SSL/TLS Certificates especially if you run nginx on Alpine Linux (but note you then need [WayBack] license_update.patch\acme-client\community – aports – Main aports tree to avoid [Archive.is] [400] does not match current agreement URL – Help – Let’s Encrypt Community Support)

Here is some more info:

Blurb: “[a] free utility to send & receive network packets. TCP, UDP, SSL.”
[WayBack] Packet Sender – Free utility to for sending / receiving of network packets. TCP, UDP, SSL.
[WayBack] The latest Tweets from Dan Nagle (@NagleCode). Principal SW Engineer @HARMAN_Pro. Speaker. Author packetsender.com, paydowncalc.com, cryptoknife.com, github.com/dannagle . Huntsville, AL,
[WayBack] Packet Sender – Send / Receive TCP / UDP – Android Apps on Google Play
[WayBack] dannagle (Dan Nagle) · GitHub dannagle has 23 repositories available. Follow their code on GitHub.

–jeroen

Read the rest of this entry »

Posted in Communications Development, Delphi, Development, Encryption, Hardware, Harman Kardon, Home Audio/Video, HTTP, https, HTTPS/TLS security, Internet protocol suite, Let's Encrypt (letsencrypt/certbot), OpenSSL, Power User, Security, Software Development, TCP, TLS | Leave a Comment »

badssl.com

Posted by jpluimers on 2018/01/11

I wish I had bumped into this when it got released in 2015: [WayBack] badssl.com hosted in the cloud and maintained by two people from Google and Mozilla.

Where ssllabs.com is for checking server-side certificates, this one is for checking clients against many, many (did I already write MANY?) server side configurations both good (with a varying set of security settings like cyphers and key exchanges) and bad.

One of the bad ones is expired.badssl.com which your clients should not be able to connect to without throwing a big error.

Sources are at [WayBack] GitHub – chromium/badssl.com: Memorable site for testing clients against bad SSL configs.

Before using, please read their

Disclaimer

badssl.com is meant for manual testing of security UI in web clients.

Most subdomains are likely to have stable functionality, but anything could change without notice. If you would like a documented guarantee for a particular use case, please file an issue. (Alternatively, you could make a fork and host your own copy.)

badssl.com is not an official Google product. It is offered “AS-IS” and without any warranties.

–jeroen

Posted in Communications Development, Development, HTTP, https, Internet protocol suite, Security, Software Development, TCP, TLS, Web Development | Leave a Comment »

« Previous Entries

Next Entries »

	Lars Fosdal on Security alarm provider Woonve…
	Thomas Mueller on Question got closed in May 202…
	Thaddy de Koning on Formulier voor bewindvoerders…
	Thaddy de Koning on Formulier voor bewindvoerders…
	Thaddy de Koning on Formulier voor bewindvoerders…

The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

Subscribe

Archives

Recent Comments

Recent Posts

Blog Stats

Meta title

Tag Cloud Title

Top Clicks

Top Posts

My badges

Twitter Updates

My Flickr Stream

Pages

All categories

Email Subscription

Archive for the ‘TLS’ Category

Some links on Chrome not prompting to save passwords (when Firefox and Safari do)

Which SMTP Port Should I Use? Learn Ports 25, 465, & 587 (and unofficial port 2525) | Mailgun

Port 465:

The browser wars that started on iOS (forcing Safari) and Android (forcing Chrome) now are continued on Windows 11 (forcing Edge)

One of the Let’s Encrypt’s Root Certificates expired today (and their corresponding intermediate yesterday); how is your infrastructure doing?

5 days before the Let’s Encrypt’s Root Certificate is expiring!

Tricks used by software developers to https://127.0.0.1

Result for atlassian-domain-for-localhost-connections-only.com/A with DNSSEC validation:

For my link archive: DNS over https

DNS over HTTPS

JSON DNS output

How to configure Nginx SSL/TLS passthrough with TCP load balancing – nixCraft

Packet Sender is a good tool when debugging protocols: free utility to send & receive network packets. TCP, UDP, SSL

badssl.com

Disclaimer

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

Subscribe

Archives

Recent Comments

Recent Posts

Blog Stats

Meta title

Tag Cloud Title

Top Clicks

Top Posts

My badges

My Flickr Stream

Pages

All categories

Email Subscription

Archive for the ‘TLS’ Category

Rate this:

Share this:

Port 465:

Rate this:

Share this:

Rate this:

Share this:

Rate this:

Share this:

Rate this:

Share this:

Result for atlassian-domain-for-localhost-connections-only.com/A with DNSSEC validation:

Rate this:

Share this:

DNS over HTTPS

JSON DNS output

Rate this:

Share this:

Rate this:

Share this:

Rate this:

Share this:

Disclaimer

Rate this:

Share this: