Diese "Vorschaltseite" kann doch bei verschlüsselten Verbindungen gar nicht funktionieren ... dazu bräuchte die Box entweder ein Wildcard-Zertifikat für so ziemlich jede TLD und/oder der Browser müßte praktisch alle von der FRITZ!Box vorgelegten Zertifikate klaglos akzeptieren oder es käme bei jeder Anzeige einer Seite aus der FRITZ!Box zu einer Zertifikat-Warnung.
Wenn der Browser erst einmal auf Verschlüsselung umgeschaltet hat (was bei HTTPS-URLs der Fall ist), geht ohne den Aufbau einer solchen TLS-Verbindung auch keine Um-/Weiterleitung auf eine andere Seite (glücklicherweise) - egal, ob mit oder ohne verschlüsselte Verbindung.
Da ist es auch keine wirkliche Lösung, wenn die FRITZ!Box bei einer HTTPS-Anfrage versucht, für die blockierte Site irgendein temporäres Zertifikat zu verwenden, um überhaupt eine Verbindung zustande zu kriegen - die meisten Nutzer würde vermutlich sogar dieses Zertifikat dann "pinnen" für die besuchte URL und das führt erst richtig ins Chaos, wenn man später auf die richtige Site zugreifen kann/will.
Für das Problem gibt es auch keine gute Lösung ... außer man beantwortet schon die DNS-Abfrage für blockierte Geräte mit einem passenden CNAME (anstelle der tatsächlich angefragten Domain), damit bereits der TLS-Connect auf "fritz.box" geht und die Box ihr eigenes Zertifikat verwenden kann (dann gibt es bloß beim ersten Mal die Warnung). Das ist aber meines Erachtens bei AVM einigermaßen getrennt, was die Kindersicherung und den DNS-Server angeht - und eine DNS-Abfrage muß noch lange kein (zu blockierender) Internet-Zugriff sein, wenn die Adresse bereits in der FRITZ!Box im Resolver-Cache vorliegt.
Ein ähnliches Problem ergibt sich, wenn der Client seinerseits die DNS-Auflösung noch im Cache hat und daher gar keine neue Abfrage vornimmt, sondern direkt mit der IP-Adresse verbinden will. Auch der umgekehrte Fall, daß die Box zu einer Zeit, wo sie die Internetverbindung (berechtigt) blockiert hat, mit einem "gefälschten" CNAME-Eintrag auf sich selbst verweist und nun ist der Zugriff zwar inzwischen wieder gestattet, im Cache steht aber noch die falsche Auflösung, ist nicht so ganz ohne ... auch wenn man da mit entsprechend kurzer TTL solcher Antworten etwas gegensteuern könnte.
Es ist jedenfalls nicht trivial, eine HTTP
S-Verbindung auf eine andere Seite "umzulenken" (das ist ja irgendwo auch der Sinn der Authentifizierung in TLS-Verbindungen, daß da nicht einfach jemand anderes antworten kann) und es gibt auch gute Gründe, warum selbst in TLS1.3 (
https://tools.ietf.org/html/draft-ietf-tls-tls13-26#section-1.3) nichts kommen wird, was anstelle einer vom Browser gestarteten TLS-Verbindung die "Weiterleitung" auf irgendeine andere Seite/Domain ermöglicht.
===============================================
Wenn so etwas mit einem Browser halbwegs funktioniert, liegt das meist daran, daß diese Programme heutzutage alle selbst
beim Start automatisch versuchen, ein solches Portal zu entdecken. Dazu wird irgendeine vorbereitete Seite des Browserherstellers im Internet über eine unverschlüsselte HTTP-Verbindung geöffnet (bei Firefox 59 z.B. die Seite "
http://detectportal.firefox.com/success.txt" in den Standardeinstellungen) und wenn das klappt, gibt es offensichtlich keine Beschränkung und auch keine "Vorschaltseite".
Ansonsten folgt der Browser einfach der Antwort des Portal-Servers (das ist dann meist ein "302 Moved Temporarily" - und das "vergiftet" eben keinen Cache, weder für HTTP-Inhalte noch für DNS-Einträge) und zeigt die Portalseite automatisch an oder er blendet auch nur einen Hinweis auf diese Seite in den aktiven Tab ein:
Wenn die Vorschaltseite also funktionieren soll, muß (a) der Browser die Portalerkennung unterstützen, man muß (b) den Browser "frisch" gestartet haben, damit er die Umleitung der FRITZ!Box über die Portalseite auch "entdecken" kann (außer er wiederholt diese Erkennung in regelmäßigen Abständen, wobei die Voreinstellungen meist nicht so sind, daß sie alle 5 Minuten den Zugriff prüfen) und (c) der Browser muß so eingestellt sein, daß er die Portalseite auch noch automatisch anzeigt.
Startet der Browser direkt mit einer HTTPS-URL (einige lassen die Portalerkennung auch aus, wenn sie direkt mit einer URL aufgerufen werden) oder ist die Portalerkennung abgeschaltet (bei Firefox gibt es dafür die Einstellungen rund um "captive" unter "about:config", wo man auch die abgefragte Seite und die erwartete Antwort ändern kann), wird man am ehesten mit einem Verbindungsfehler konfrontiert werden, weil die Umleitung der FRITZ!Box eben keine TLS-Verbindung ist, wie der Browser eine erwartet.
Hier könnte AVM (für die Browser, die entsprechende Einstellungen erlauben) vielleicht auch eine eigene "Internetzugang ist möglich"-Seite anbieten ... dann könnte der Kunde die Browser auf den betroffenen Geräten entsprechend einstellen, daß sie bereits beim Start deutlich "ansagen", wo das Problem bei einer zeitlichen Limitierung liegt. Andererseits antwortet die FRITZ!Box ohnehin mit einer 302-Umleitung bei gesperrtem Internet-Zugang und da steht das im Prinzip ebenso drin ... nur fehlt halt die "positive Seite" für den "erlaubten Internet-Zugang" und es wird nur der Mißerfolg angezeigt.
